-
Notifications
You must be signed in to change notification settings - Fork 22
Description
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. π€¦ββ π€¦ββ π€¦ββ