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

Spring webflux - ControllerAdvice ExceptionHandlers execute before backstopper #52

Open
nicmunroe opened this issue Feb 29, 2020 · 0 comments

Comments

@nicmunroe
Copy link
Member

In Spring MVC, a @ControllerAdvice bean that defines a @ExceptionHandler executes after the global HandlerExceptionResolvers, which is where Backstopper's error handling hooks in for Spring MVC. So the Backstopper handlers always go before any @ControllerAdvice @ExceptionHandlers.

But in Spring WebFlux, these @ControllerAdvice beans' @ExceptionHandlers always execute before any of the global WebFlux WebExceptionHandlers, which is where Backstopper's error handling hooks into Spring WebFlux. So in WebFlux, the Backstopper handlers always go after any @ControllerAdvice @ExceptionHandlers. 🤦‍♂

This means that in WebFlux, any @ControllerAdvice @ExceptionHandlers will hijack error handling control away from Backstopper.

This ticket is for investigating the best way to give error handling control back to Backstopper in these situations.

This likely means defining a Backstopper @ControllerAdvice (for WebFlux only) that injects the SpringWebfluxApiExceptionHandler and SpringWebfluxUnhandledExceptionHandler. It would have an @ExceptionHandler that handles all exceptions, and would go through the two backstopper handlers to find a result to return.

Note that if an @ExceptionHandler method is called, it must handle the exception, unlike the usual global spring handlers (e.g. WebExceptionHandler) that let you defer handling to other handlers. This complicates things.

Ordering will be important. Note that there's a bug in Spring 5.1.x with ControllerAdviceBean where it doesn't honor the Ordered or PriorityOrdered interfaces contrary to the explicit javadocs on @ControllerAdvice, so the only way to order a @ControllerAdvice in Spring 5.1.x is with the @Order annotation, which can't have a dynamic order value at runtime based on config. 🤦‍♂ Spring 5.2.x is better in that it honors the Ordered interface, but it still doesn't honor PriorityOrdered. 🤦‍♂ 🤦‍♂ 🤦‍♂

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant