Feliks Khantsis opened SPR-15489 and commented

The documentation at 22.11.2 says that

Much like standard controller methods annotated with a @RequestMapping annotation, the method arguments and return values of @ExceptionHandler methods can be flexible.

However in reality, ExceptionHandlerExceptionResolver#getDefaultArgumentResolvers is much skimmer than RequestMappingHandlerAdapter#getDefaultArgumentResolvers. There is no documentation which resolvers are or are not part of ExceptionHandlerExceptionResolver's defaults.

Specifically, I need RequestHeaderMethodArgumentResolver. My use case is that server requirements changed, and now under certain conditions, the server must not accept a request, and return 400-BadRequest. However since some clients are not yet updated, this will cause them to crash. Therefore, new clients send a custom header to say that they are ready to receive 400-BadRequest. Thus, in the @ExceptionHandler method, if the new header is set, then we can return 400, otherwise, keep returning 200. Unfortunately, I can't get the header via @RequestHeader, since RequestHeaderMethodArgumentResolver is not in ExceptionHandlerExceptionResolver.

At best, you should equate all default handlers for ExceptionHandlerExceptionResolver and RequestMappingHandlerAdapter. If that's impossible, then at least go through all argument resolvers that are not in ExceptionHandlerExceptionResolver, re-evaluate if it's impossible to move it to Ex.HandlerEx.Resolver, and have clear documentation in 22.11.2 as for which argument and return value handlers are supported, and which are not.

No further details from SPR-15489

Comment From: rstoyanchev

This is an old issue but for starters this is at least documented now: https://docs.spring.io/spring-framework/docs/current/reference/html/web.html#mvc-ann-exceptionhandler-args

The list of argument resolvers and return value handlers does differ for a reason. Notably data binding and request body deserialization don't make sense or cannot be done. A number of others could be added but haven't been and have not been requested either. At this point I would add more on a case by case basis, i.e. as needed.

In the mean time you should be able to add the RequestHeaderMethodArgumentResolver or others as a custom argument resolver via WebMvcConfigurer#extendMessageConverters.

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.