Revisit MVC ResponseEntityExceptionHandler

[bclozel]

The ResponseEntityExceptionHandler handles exceptions at the MVC/WebFlux level as Problem Details. Right now, only machine-readable formats are managed.

The Spring Boot global error handling not only handles JSON, but also static pages and view templates. This infrastructure is currently based on an ErrorController and an ErrorAttributes object. Errors are handled during error dispatches.

Errors should be as much as possible handled by the application, error dispatches should be the last resort. Spring Framework should help applications by providing a flexible mechanism for rendering errors as HTML. For that, we can probably lean on content negotiation support and the ordering of handlers.

[YongGoose]

@bclozel

I think this issue could benefit many users. I’d be interested in working on it.
Is it okay for a community member to take this on?

Even if the core team decides to handle this, I’d be more than happy to help with the design :)

[bclozel]

@YongGoose thanks for the suggestion. I'm not sure how we can implement this, and this issue is currently assigned. So not really a good candidate for community contribution.

[bclozel]

After experimenting in the Spring Boot codebase, I have come to following conclusions.

First, Framework doesn't seem to need additional support for rendering views, besides the existing view rendering support and content negotiation support for error handling. As for rendering errors as views in Framework, this is quite opinionated and we can't really make such assumptions directly in Framework. Implementing a simple strategy is straightforward.

ResponseEntityExceptionHandler is an abstract class that can be extended and declared as a @ControllerAdvice in applications to handle exceptions thrown by Spring MVC itself. This class started out as a common starting point for applications, but since we expanded error handling in several ways: we now support the ProblemDetail RFC and we also support content negotiation.

We should then revisit ResponseEntityExceptionHandler to better help with these new use cases, by:

• introducing a new type that better conveys that its main goal is to handle exceptions raised by Spring MVC (i.e. not by the application itself). We should also consider if we should deprecate the existing type, introduce a new hierarchy...
• creating a new abstract type that focuses on turning exceptions into ProblemDetail instances. This will help with Render global errors as Problem Details spring-boot#43850 as Spring Boot could rebase a large part of its error handling infrastructure on top of that.

[xak2000]

Probably spring-projects/spring-security#13598 could potentially benefit from this.

There is definitely not just MVC exceptions in any app, and it would be great to have a unified and straightforward mechanism to handle different kinds of exceptions. dispatcherServlet vs Sevelet Filter vs Spring Securty, etc. Currently it's a mess. Some exceptions are handled in one way, some in a different way, and it is hard to remember which are handled how and keep in your head all possible ways and places they can be handled.