Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Have ExceptionHandlerMethodResolver use most-specific ExceptionHandler method [SPR-11016] #15644

Closed
spring-projects-issues opened this issue Oct 22, 2013 · 4 comments
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process

Comments

@spring-projects-issues
Copy link
Collaborator

Deejay opened SPR-11016 and commented

It'd be good to have exceptions handled by the @ExceptionHandler with the most specific exception type defined. At the moment, it appears to be handled by whichever handler it finds first that can deal with any type in the exception's ancestry.

Jersey's similar ExceptionMapper mechanism iterates over each handler, then iterates up the type ancestry of the exception, counting as it goes. The handler with the shortest distance between the exception's actual type and the handled type wins and is returned. This could be cached for efficiency.


Reference URL: http://stackoverflow.com/questions/19498378/setting-precedence-of-multiple-controlleradvice-exceptionhandlers/19500823

@spring-projects-issues
Copy link
Collaborator Author

Rossen Stoyanchev commented

The logic for selecting @ExceptionHandler methods is using org.springframework.core.ExceptionDepthComparator (this is from ExceptionHandlerMethodResolver) so if you have two methods, the one with the more specific exception should be selected.

Can you provide a concrete example? A executable example would be best but code snippets of controller and exception handling method signatures would be okay as well.

@spring-projects-issues
Copy link
Collaborator Author

Deejay commented

Hi, I've raised a pull request for the Spring Framework Issues repo with a small project that demonstrates the issue.

There are three tests in ExceptionHandlerTest. exceptionHandledByCatchAll should pass, and the other two (uncheckedExceptionHandled and checkedExceptionHandled) should fail, as those @ExceptionHandlers are never invoked.

BTW Maven didn't pick up the tests on the command line, but did through STS.

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Nov 4, 2013

Rossen Stoyanchev commented

Thanks for the example! The tests pass for me but despite that they show me exactly what you mean.

The feature was designed to work like this. The first @ControllerAdvice to return an exception handling method "wins". You can order them by adding @Order or implementing Ordered.

On a related note we have also recently added more fine-grained control over what controllers an @ControllerAdvice applies to (see #14855).

I'd be interested to know if your use case can be served by the above?

@spring-projects-issues spring-projects-issues added status: waiting-for-triage An issue we've not yet triaged or decided on type: enhancement A general enhancement in: web Issues in web modules (web, webmvc, webflux, websocket) labels Jan 11, 2019
@spring-projects-issues spring-projects-issues removed the type: enhancement A general enhancement label Jan 11, 2019
@rstoyanchev rstoyanchev added status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Jan 11, 2019
@spring-projects-issues
Copy link
Collaborator Author

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: bulk-closed An outdated, unresolved issue that's closed in bulk as part of a cleaning process
Projects
None yet
Development

No branches or pull requests

2 participants