Christopher Smith opened SPR-15645 and commented
I can annotate an exception type with @ResponseStatus to indicate "in-band" what sort of error should be returned to the client, and this works seamlessly with ResponseEntity-type responses. However, when I want to display an HTML error page, I use an @ExceptionHandler method that handles that particular exception type. Unfortunately, @ExceptionHandler methods can themselves take @ResponseStatus annotations, and if they don't, the default behavior (generally a 200) is applied, so that duplicating the status values is necessary.
In the case where an @ExceptionHandler's argument is annotated with an @ResponseStatus and the handler itself has no status type, I suggest that the response status code should be set from the exception's value instead of using the default strategy.
Affects: 4.3.9
Comment From: bclozel
Sorry it took us so long to respond to this issue. In the meantime, the error handling story had many enhancements, including the RFC problem details support.
Looking at the different error handling strategies supported and how exceptions can be resolved and mapped to @ExceptionHandler methods, I don't think we should implement this enhancement.
With this, a method argument (multiple exception types can be mapped) would have an effect on the HTTP response. Worse, if the handler doesn't completely handle the exception, the error bubbles up to other error handling mechanism after this side effect. I think the error handling strategies listed in our reference documentation have well defined perimeters and responsibilities and we should avoid interactions.
There hasn't been much demand for this, so I'm closing this issue.