The FieldError class does not provide access to the exception that triggered the binding error. [SPR-16372]

[spring-projects-issues]

Razvan Popian opened SPR-16372 and commented

It would be nice if the org.springframework.validation.FieldError class would provide access to the actual exception that triggered the binding error. That exception might be thrown in a Converter or Formatter and it could be helpful for somebody who is trying to get more details about why a certain field failed to bind.
Currently the org.springframework.validation.FieldError class does store the exception message, but it would be better if it would store the actual exception (See the org.springframework.validation.DefaultBindingErrorProcessor#processPropertyAccessException method).
There are definetely workarrounds to achieve this by extending FieldError and by injecting a custom BindingErrorProcessor in the DataBinder, but I think it would be nice if the framework would do this out of the box.

---

Affects: 4.3.6

Issue Links:

• Cannot create BindStatus for valid field on immutable form object in case of bind errors [SPR-16449] #20994 Cannot create BindStatus for valid field on immutable form object in case of bind errors

Referenced from: pull request #1654

[spring-projects-issues]

Juergen Hoeller commented

I've addressed this in a rather general way, following up on the refactoring in #20994: ObjectError carries a source object now which will typically be an Exception or a Bean Validation ConstraintViolation and is therefore typed as Object.

[spring-projects-issues]

Juergen Hoeller commented

According to spring-projects/spring-boot#11894 (comment), the new getSource() method is unfortunately mistaken as a bean property and potentially rendered out like that. Let's consider a different access style to the underlying source exception/violation.

[spring-projects-issues]

Juergen Hoeller commented

I've revised this towards an unwrap(Class) and contains(Class) pair of accessors which turns out to be pretty convenient to use for the typical cases, in particular also for direct access to the cause of the outermost binding exception (e.g. the conversion exception or an exception thrown from a setter method, instead of having to manually unwrap the PropertyAccessException).