@ExceptionHandler cannot handler java.lang.Error despite the annotation accept ? extends Throwable [SPR-11106]

[spring-projects-issues]

Jiri Mikulasek opened SPR-11106 and commented

according to http://docs.spring.io/spring/docs/3.0.x/api/org/springframework/web/bind/annotation/ExceptionHandler.html
@Exceptionhandler should allow to handle also Errors, however it can't, cause DispatcherServlet doesn't catch and deliver that to ExceptionHandler

---

Affects: 3.2.4, 4.2.5

Reference URL: http://stackoverflow.com/questions/8184593/why-error-is-not-getting-caught-even-when-explicitly-thrown/8212177#8212177

Issue Links:

• After-completion callback not triggered for custom Throwable subclass [SPR-14329] #18901 After-completion callback not triggered for custom Throwable subclass
• AbstractMethodMessageHandler does not rethrow Errors [SPR-16912] #21451 AbstractMethodMessageHandler does not rethrow Errors
• @ExceptionHandler should match cause as well (e.g. for exception thrown from argument formatter) [SPR-14291] #18863 @ExceptionHandler should match cause as well (e.g. for exception thrown from argument formatter)

2 votes, 4 watchers

[spring-projects-issues]

Yuriy Nakonechnyy commented

I highly agree with this issue - very often it makes a lot of sense to handle Errors e.g. for logging purposes and currently this is very big limitation of Spring which is very easy to change and fix (at least it looks like this).

Please refer to the list of absolutely valid arguments for allowing this:

1. As per comment of Juergen Hoeller - even OutOfMemoryError is totally recoverable in some cases
2. I had one case when I got UnsatisfiedLinkError during runtime and I couldn't log it properly because of this problem. It was caused by one library using native methods only in hanlding of one request, so it was perfectly recoverable and affected only small part of webapplication, allowing other parts of it work flawlessly

That's why I believe that this issue should be on the top of backlog for future releases due to relatelively easy implementation of it

[spring-projects-issues]

Yuriy Nakonechnyy commented

Also in Affects Versions field of this issue only version 3.2.4 is mentioned, however this issue affects all versions up to version 4.2.5 - could someone please update this field or give me rights to update it?

[spring-projects-issues]

Juergen Hoeller commented

This is indeed easy enough to address: We're wrapping such Errors in NestedServletException for processing purposes in other places already, in particular for the clean-up phase of handler interceptors. We can arguably do this for exception resolvers as well, with each such resolver receiving the NestedServletException then, being able to consider the nested root cause as well. Allowing ExceptionHandlerExceptionResolver to handle a root cause mapping is then all that it takes to make this work.

I've implemented this already and it works fine for me here. If I don't find any undesired side effects, I'll roll this into 4.3 RC1.

[spring-projects-issues]

Yuriy Nakonechnyy commented

Hi Juergen!

Thanks a lot for fantastically quick fix, that was incredibly fast :)

Kind regards,
Yuriy

[spring-projects-issues]

Yuriy Nakonechnyy commented

Just a short question: will implemented solution allow handling of classes that extend Throwable but not Error or Exception?
I know that's very rare cases and probably it's more like anti-pattern to have such classes but still that may happen, so I wonder if such cases are also covered.

[spring-projects-issues]

Juergen Hoeller commented

We can't propagate custom Throwables through the MVC processing contracts, so there is no need to explicitly handle them at the exception handler level. Technically, you'd get an IllegalStateException if you were trying to throw a non-Exception/Error from an MVC handler method.

[spring-projects-issues]

Yuriy Nakonechnyy commented

Ah, ok - throwing IllegalStateException for custom Throwables makes a lot of sense, thanks!