Allow SimpleMappingExceptionResolver to navigate exception "cause" hierarchy [SPR-5053]

[spring-projects-issues]

Kenny MacLeod opened SPR-5053 and commented

In some cases, a business logic exception ends up being wrapped in some other exception by the time it gets to the HandlerExceptionResolver. This means that the likes of SimpleMappingExceptionResolver cannot easily handle it.

An example would be I have a FactoryBean which can throw a business logic exception during the creation of the object. The factory bean is in the context as a scoped proxy. When the proxy is dereferenced and the factorybean throws the business logic exception, the exception is wrapped in layers of spring BeanFactory exceptions as it rolls back up the AOP stack. This is fine, except I cannot then directly configure the original business logic exception in the SimpleMappingExceptionResolver.

If SimpleMappingExceptionResolver were able to walk up the tree of root cause exceptions (there may be JDK compatibility issues there), then it could peel the onion and handle the original exception accordingly.

---

Affects: 2.5.5

Issue Links:

• @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)

5 votes, 9 watchers

[spring-projects-issues]

Juergen Hoeller commented

Good idea!

Since Spring 2.5 requires JDK 1.4.2+, we can easily bake in "getCause()" analysis. We generally revised Spring 2.5's exception cause handling to take full benefit of JDK 1.4's exception chaining.

What would you expect to happen if you had a matching exception mapping for both the outer exception and its cause? For example, a DataAccessException that wraps a HibernateException. I would argue that if the outer exception matches, it will always be its mapping taking precedence, only falling back to the cause mapping otherwise... However, what would you expect if there was a mapping entry for "java.lang.Exception"? With the rule above, that would obviously always match the outer exception, so the cause will never ever get checked...

Juergen

[spring-projects-issues]

Kenny MacLeod commented

Yeah, that could get tricky. Perhaps a sensible default would be to just keep the behaviour as it is, and have a flag on the resolver which tells it to check root causes first? I'm not sure there's a general algorithm which would make sense in all cases.

[spring-projects-issues]

David Tarico commented

I think it makes most sense to walk the exception root-cause chain starting with the deepest root cause, because my intent is to give the user the most specific error message possible, and typically that specific information about the precise error is in the deepest root cause, and the information gets more generalized as you go up towards the top level exception.

For example, the ManagedConnection from Java Connector Architecture throws a ResourceException, which extends directly from Exception. For my underlying resource, I use another Telnet package that throws specific exceptions like "TelnetTimeoutException" or "HostNotFoundException", and all these specific exceptions are have to be wrapped in a ResourceException. I want to have a specific error page for TelnetTimeoutException, and also map ResourceException to a generic error page about connecting the database. In this example, I do want to map ResourceException separately from Exception because ResourceException tells me a rough what the problem was.

This generically wrapping all exceptions inside of a project-specific exception happens a lot when combining projects developed by different people that tackle different abstract layers, and hence they have different exception hierarchies that don't have a common root other than Exception.

If there's a strong case for going top down to root, the direction to walk the exception chain could be a configuration option.

But for worrying about matching java.lang.Exception, it doesn't matter if you start at the top level or root-cause because they will all match Exception and prevent walk the chain. It's probably best to make exception-chain walking an option you have to turn on. Then the javadoc for the configuration setting would warn users that a generic mapping for all exceptions should not be used with exception-chain walking. A catch-all for every exception would need to be in a separate SimpleMappingExceptionResolver, since you can also "chain" those together.

The one thing I'm not sure of is how exception-chain walking would combine with exception-hierarchy walking. My first inclination is to try and match the root cause, and then all of the exceptions it extends from, before moving on to the next exception in the cause-chain. But I'm trying to think if there's an example where you wouldn't want that.

Take my previous example of TelnetTimeoutException and ResourceException, and say TelnetTimeoutException extends IOException. If I didn't have a mapping for TelnetTimeoutException, I might want to give an error page based on ResourceException because that tells me the error was related to connecting to the database, but I might also have a mapping for IOException that tells me something generically went wrong with IO somewhere. In this case, I might say the ResourceException is more specific because I know it had to do with a database connection.

But honestly this example feels contrived, because having a mapping for IOException really isn't useful and you might as well just let the mapping for java.lang.Exception catch it.

[spring-projects-issues]

Bindiya commented

Any plans for fixing this issue at the earliest?

[spring-projects-issues]

Mike Boyers commented

I am also interested in this, are there any plans to address it?

[spring-projects-issues]

Juergen Hoeller commented

Closing groups of outdated issues. Please reopen if still relevant.

[spring-projects-issues]

Juan Carlos García del Canto commented

I've created #18863 improvement related with this issue. I've saw that in previous discussions you have been talked about the problem of navigate the cause only if there's not exists any mapping to root exception, but I think that could be interesting have this solution too, to be able to map only custom exceptions that will be available only checking the cause.

I've related this issue with the new one.

Regards,