Flexible return types (including void) in JAX-RS exception handling — is a ControllerAdvice-style mechanism feasible natively?

[cj19]

Hi,
We're investigating whether Quarkus supports — or could support — a global, annotation-driven exception handling mechanism that is not tied to the HTTP response pipeline, but works across the entire application layer.

The core problem

JAX-RS ExceptionMapper is HTTP-centric by design — its sole purpose is to convert exceptions into Response objects. We're looking for something more general: a cross-cutting exception handler that can intercept exceptions regardless of where they are thrown (service layer, repository layer, background jobs, etc.), execute arbitrary logic, and optionally produce a result — without being constrained to return a Response or any specific type.
In Spring, @ControllerAdvice + @ExceptionHandler is HTTP-scoped, but CDI interceptors and AOP (@Around advice) can handle this more general case. We're looking for the Quarkus equivalent.

What we'd like to achieve

Something like:
@GlobalExceptionHandler // custom annotation we'd define

public class MyExceptionHandlers {

    @Handles(MyBusinessException.class)
    public void onBusinessException(MyBusinessException ex) {
        // log, notify, compensate, etc. — no HTTP concern here
    }

    @Handles(MyBusinessException.class)
    public Uni<Void> onBusinessExceptionReactive(MyBusinessException ex) {
        // reactive variant
    }

    @Handles(MyBusinessException.class)
    public MyResult onBusinessExceptionWithResult(MyBusinessException ex) {
        // optionally produce a fallback/recovery value
    }
}

Key requirements:

• Handler methods can have any return type, including void and reactive types (Uni)
• Works outside the HTTP layer — service beans, event consumers, scheduled jobs, etc.
• Centralized — handlers are defined in one place, not scattered across try/catch blocks
• Ideally CDI-aware so handlers can inject other beans

Questions

1. Is there an existing Quarkus/CDI mechanism that supports this today — e.g. CDI interceptors, Vert.x event bus error handlers, or ArC-specific hooks?
2. Would a custom annotation backed by a CDI interceptor + build-time extension be a realistic approach? Are there known limitations (e.g. GraalVM native, ArC proxy restrictions) that would make this difficult?
3. Is there prior art in the Quarkus ecosystem — extensions or community libraries — that already solve this at the application layer rather than the HTTP layer?
4. If we were to contribute something like this, which SPI would be the right entry point — ArC, the RESTEasy Reactive exception handling chain, or something else entirely?

We're aware of related HTTP-scoped issues #5392, #4042, and #11557 but those are all constrained to the HTTP pipeline, which is not our primary goal here.
Thanks for any guidance!

[cescoffier]

/CC @geoand

[geoand]

Thanks for bringing this up.

Does what you describe (or something similar) really work in Spring Boot? Can you show me an example?
Moreover, let's take the case of

    @Handles(MyBusinessException.class)
    public MyResult onBusinessExceptionWithResult(MyBusinessException ex) {
        // optionally produce a fallback/recovery value
    }

When that is triggered, where is the value returned to?

[cj19]

hi @geoand!
i have nothing implemented yet in my quarkus app, but i know that spring makes this kind of error handling possible.
i was wondering whether something similar is possible in quarkus or not, because the other discussions on github is bit misleading.

[cj19]

Well, centralized handler buys you:

• One place handles MyBusinessException everywhere, automatically.
• New methods get the handling for free without any annotation.
• Cross-cutting concerns (logging, alerting, metrics) live in one place.
• The fallback logic and the business logic are cleanly separated.

is there a solution in quarkus that similar to this? Can you suggest an approach?

[geoand]

is there a solution in quarkus that similar to this?

There is not, but as I'm still not convinced, I'd be very willing to run an example of what you have in Spring Boot to try to see in practice why this approach is superior

[cj19]

it's described here, see Global Exception Handling chapter:
https://spring.io/blog/2013/11/01/exception-handling-in-spring-mvc
the other parts besides the response handling based on exception done using Spring AOP.
https://docs.spring.io/spring-framework/docs/2.0.3/reference/aop.html

[cj19]

@geoand i will create an example project (asap) to showcase what i want to do.

[geoand]

🙏🏽

[cj19]

hi @geoand !

I have just pushed a demo app to showcase the exception handling that i try to have in quarkus app.
Let me know what you think about it, after you've checked it out!
Thanks

[geoand]

Yeah, it's definitely not an OOTB Spring thing

[cj19]

Can we draw any conclusions from this discussion?

[geoand]

A few points:

• No Aspects in Quarkus and (almost certainly never will be)
• Whether you build something on your own with interceptors or some quarkiverse extension will do the job, you'll need to opt-in to the exception handling, likely using an annotation
• CDI interceptors will likely be the backbone of any solution to this

[Ladicek]

It is entirely possible to write a Quarkus extension that would do what you want. It wouldn't even be very big. But it feels fair to say this will not become part of Quarkus proper.

[cj19]

okay, got it. if you have an add-on in mind that could do this, please share it.

[MILLERMARRU]

[cj19]

hi @MILLERMARRU, thanks for your comment. It is a pretty good approach, but I am not sure that it covers every case.

[Ladicek]

This is such an obvious AI slop I don't even know what to say. So I'll just point out that:

1. ArC does support self interception. If you're calling a non-private method on this and there are interceptor bindings that apply to that method, it will be intercepted.
2. Quarkus (not ArC on its own, but the Quarkus extension for ArC, to be super precise) does support intercepting static methods (obviously if they are not private). Only method-level interceptor bindings apply, but that's mostly out of compatibility concern, not a technical limitation.

[Ladicek]

For the record, this is documented in https://quarkus.io/guides/cdi-reference, so it's not a secret.

[geoand]

This is such an obvious AI slop I don't even know what to say

At least someone else used their own tokens to produce it 😆