Add system that can globally convert any exception to an ErrorResponse

[mzeijen]

As a user I would like a system that can convert any exception that is thrown during request processing to an ErrorResponse. This also includes exceptions that can be thrown before the @ExceptionHandler methods can handle exceptions. This should allow the server to always respond with an ErrorResponse for any exception.

To make this possible, I propose creating a system where converters can be registered that take an exception (and possibly any other relevant HTTP request information) and convert them to an ErrorResponse instance. Spring can itself provide default converters for all its exceptions, but users should also be able to provide their own converters. Either to override the default converters from Spring or to be able to convert their own exceptions globally.

The converters should be ordered, and the converter with the highest precedence should be used when multiple converters can be applied to a specific exception.

By providing a converter that can convert Throwable to an ErrorResponse, there can be a catch-all converter for those exceptions for which no converter or higher-level @ExceptionHandler was defined.

This system can be a replacement of the ResponseEntityExceptionHandler class, although it probably should still stick around for a while for backwards compatible reasons.

Note: I have discussed this feature request with @rstoyanchev at Spring I/O 2023

[rstoyanchev]

Thanks for raising this.

Generally, I understand the goal is to convert Throwable to ErrorResponse, but we already have such a mechanism. @ExceptionHandler methods on Controller or ControllerAdvice can map Throwable to ErrorResponse.

Note that all Spring Web exceptions are implementations of ErrorResponse. So all that ResponseEntityExceptionHandler does is to return them from an @ExceptionHandler method, without conversion. Its secondary purpose is to allow customization either in code through protected methods, or through a MessageSource.

In summary, exceptions can implement ErrorResponse and be handled automatically in ResponseEntityExceptionHandler. For others, use @ExceptionHandler methods to map Throwable to ErrorResponse.

So I'm wondering what's actually missing?

[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.

[mzeijen]

Dear spring-projects-issues bot, I am still intended to look at this, but I first need to do some other things ;).

The following I already e-mailed to Rossen directly:

Regarding on the conversion from Throwable to ErrorResponse I agree it needs some more clarification. In its current form it is just an alternative to the ResponseEntityExceptionHandler implementation. If that is only what it is, then I agree it might not be worth the effort. However, I think there is possible still a reason to consider changing it a bit. It might not need to be as flexible as the system I propose though. The reason is a suspicion I have: A while ago, we also considered getting rid of our own conversion system in our problem implementation, in favor of using just exception handlers to do all conversions. However, we hit some limitations that it wasn’t possible to apply it for every type of common web exception and that is why we kept the current “flexible” implementation. I am not sure though if the ResponseEntityExceptionHandler has the same limitations, so I need to do some investigation in to that.

If I find any issues then I will either create new issues for them, or if I believe it requires the conversion system to be overhauled, I will add it to the existing issue on exception conversion. If I don’t see any reason for the conversion system to be overhauled, then I will close the ticket.

It might take me a couple of weeks before I have time to do the investigation, so a response might take a while.

[rstoyanchev]

@mzeijen, no worries at all, take your time!

[mzeijen]

I am closing this issue, because there is no real need for it. I have done extensive testing, and the situations for which we needed a more complicated implementation in our own custom ProblemDetail implementation, are not a problem with this implementation. I think the reason because changes are made in several core Spring components to facilitate ProblemDetail support, that solve the issues we ourselves encountered with our custom implementation.

There are two situations thought which changes in the Spring Framework and Spring Boot would be appreciated, to make it easier for us to switch from our custom implementation to the default implementation:

• Getting Problemdetail response when a 404 occurs is still problematic. I created the issue The ResourceHttpRequestHandler and ResourceWebHandler prevent returning 404 Not Found ProblemDetail responses #30847, which explains why that is, including tests that show this.
• The ProblemDetailsExceptionHandler beans are currently not ordered, which isn't ideal when you we want to add a catch-all exception handler that must be ordered after the ProblemDetailsExceptionHandler bean. A workaround is to define our own ProblemDetailsExceptionHandler like beans, but this can be prevented by simply giving the ProblemDetailsExceptionHandler an order. I created a pull request in the Spring Boot project to address this: Order ProblemDetailsExceptionHandler beans spring-boot#36288

[rstoyanchev]

Thanks for the feedback @mzeijen. The 404 handling was addressed for 6.1 with #29491 and is available in M2.