Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support way to extract ConstraintViolation from HandlerMethodValidationException #33025

Closed
kiwonseo opened this issue Jun 14, 2024 · 2 comments
Closed
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Milestone

Comments

@kiwonseo
Copy link

kiwonseo commented Jun 14, 2024

Affects: 6.1.x or higher


I have been migrating from AOP method validation via @Validated to Spring MVC built-in method validation, added in 6.1, for queryString variable with @Constraint annotations on my controller. I have noticed that there is no simple way to extract the cause of newly thrown HandlerMethodValidationException when replacing old handler method for ConstraintViolationException.

Despite the fact that document describes HandlerMethodValidationException is "very similar" to the good old
MethodArgumentNotValidException, it lacks of the way to extract the source, ConstraintViolation while with MethodArgumentNotValidException from validating @RequestBody, you could get simply get it through ObjectError or FieldError in the exception.

HandlerMethodValidationException from validating queryString only contains DefaultMessageSourceResolvable. I think if it contains some kind of "ViolationParameterError" or something just like MethodArgumentNotValidException, it would be great to have unifying handler method for any validation exceptions from controller layer.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jun 14, 2024
@snicoll snicoll added the in: web Issues in web modules (web, webmvc, webflux, websocket) label Jun 14, 2024
@rstoyanchev
Copy link
Contributor

For ParameterErrors (nested validation errors), you get FieldErrors adapted from ConstraintViolation in exactly the same way as with MethodArgumentNotValidException. For example this works:

ex.getBeanResults().get(0).getAllErrors().get(0).unwrap(ConstraintViolation.class)

Or if using the Visitor on HandlerMethodException, you can do similar to the above but with a shorter path since you have the specific ParameterErrors instance:

parameterErrors.getAllErrors().get(0).unwrap(ConstraintViolation.class);

It's true, however that for all others (violations directly on method parameters) we expose only a MessageSourceResolvable.

We could maybe expose a lookup method on ParameterValidationResult that takes aMessageSourceResolvable and returns the ConstraintViolation, or add a getConstraintViolations() method that returns List<ConstraingViolation> in the same order as getResolvableErrors().

@rstoyanchev rstoyanchev added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Jun 19, 2024
@rstoyanchev rstoyanchev added this to the 6.2.x milestone Jun 19, 2024
@rstoyanchev rstoyanchev self-assigned this Jun 20, 2024
@rstoyanchev rstoyanchev modified the milestones: 6.2.x, 6.2.0-M6 Jul 12, 2024
@rstoyanchev
Copy link
Contributor

There is an now an unwrap(MessageSourceResolvable error, Class<?> sourceType) method on ParameterValidationResult similar to the one on ObjectError.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

4 participants