According to RFC-7807 (see https://tools.ietf.org/html/rfc7807) it would be useful to provide an invalid-params field in case of 400 Bad Request errors. This field is supposed to contain ALL violated parameters, no matter which Exception type is caught by the ExceptionHandler annotated methods.

Since in case of multiple violations it is possible that Exceptions of different types occur (e.g. ConstraintViolationException and MethodArgumentTypeMismatchException from one request), those Exception objects must be available in the ExceptionHandler.

A solution would be a resolver for a List of Exceptions.

Comment From: bclozel

We could use this issue as the basis for a broader rfc7808 "Problem Details for HTTP APIs". Spring Boot has an issue about this (see spring-projects/spring-boot#19525), but we're likely to need infrastructure support from Spring Web Frameworks.

Comment From: dirweis

Great, thank you, @bclozel ! Maybe you can use my second Issue in Exception Handlers as well as the basis for a broader rfc7808 "Problem Details for HTTP APIs": https://github.com/spring-projects/spring-boot/issues/25105

Comment From: npathai

I can work on this if it's available. I am a first time contributor, do let me know if this is something a first timer can take a dig on.

Comment From: bclozel

Hello @npathai

I've tagged this issue with "status: pending-design-work".

In this case, we know that Spring HATEOAS and 3rd party Spring Boot starters provide features in this space. We don't know how this would be support in Spring Framework yet. From turning business exceptions into problem details instances, providing an error handling infrastructure, helping to localize error messages and URLs to error pages, etc. Some of this could be in Spring Framework, other parts should belong in Spring Boot.

We know that this feature requires significant changes and we'd like to tackle it in the Spring Framework 6.x timeline.

We're happy to have community members like you willing to help. In general, you should try and look for "status: ideal-for-contribution" issues. Arguably, they're not really common in Spring Framework because many issues are really specific, but other Spring projects have more of those. Many community members start by contributing documentation improvements, fixing typos, or answering questions on StackOverflow.

Thanks!

Comment From: npathai

@bclozel Sure, sounds reasonable. Thanks for the insight. I contribute in other projects but was starting to look into open issues in Spring. I will look into other Spring projects 👍

Comment From: rstoyanchev

@dirweis there is only a single exception that is raised and resolved through the HandlerExceptionResolver contract. So it would be ConstraintViolationException or MethodArgumentTypeMismatchException, never both. Can you clarify what you have in mind?

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: dirweis

@rstoyanchev What can I explain deeper hereby? What is not clear? I'm aware that only a ConstraintViolationExceptionor MethodArgumentTypeMismatchException or any other type of exception can be caught in an Exception Handler at once, never both or 3 or n for n>1 at the same time. And I would really appreciate if that would be possible, no matter what Exception type. I can imagine this poor fella had something similar in mind: https://stackoverflow.com/questions/4221064/spring-exceptionhandler-handling-multiple-kinds-of-exceptions

Have an ice weekend, Dirk

Comment From: rstoyanchev

@dirweis when the issue was originally accepted, the intent was to support for RFC 7807. We now have an official umbrella issue #27052 and I'm looking at the specifics of your request.

You seem to be asking for some variant of the HandlerExceptionResolver that can handle multiple exceptions at the same time. That doesn't make sense because as soon as there is an exception it bubbles up and we look for a HandlerExceptionResolver to resolve it. In other words we will never have more than one exception to handle at once.

The StackOverflow question you referenced on the other hand is about how to handle different exceptions types in the same way, not at the same time.

In terms of the RFC 7807 invalid-params, I haven't looked very closely but I imagine that when we translate ConstraintViolation errors from a JSR-303 validator into a BindException, all the validation issues could be listed in invalid-params. So this could be a fit for exceptions that list multiple problems, even if I can't think of any other (built-in) exceptions that fit that description.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: spring-projects-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.