Customize list of exceptions to unwrap in resteasy-reactive about quarkus

[gsmet]

Oh yeah, I totally agree but I wanted to know the use case as it might be something we want to add as default anyway for better user experience.

[quarkus-bot]

/cc @FroMage (resteasy-reactive), @geoand (resteasy-reactive), @stuartwdouglas (resteasy-reactive)

[geoand]

I think this makes sense

[gsmet]

Is it a custom exception that you want to unwrap? Or something that would make sense in general?

[geoand]

It makes sense to have this be configurable.
I planned to do it when someone asked 😀

[geoand]

One question I do have however is whether the feature should be enabled by a configuration property or some new annotation.

The reason the configuration property (although totally reasonable) can be suboptimal is that the IDE doesn't provide any assistance or validation of the value

[geoand]

#42094 is what I have in mind

[kevinferrare]

Thank you for the quick and welcoming feedback!
@gsmet

Is it a custom exception that you want to unwrap? Or something that would make sense in general?
It is both, we have java.util.concurrent.CompletionException and a custom exception, thrown by an internal library.

@geoand
After opening the issue, I started to wonder what would be the drawback of also optionally providing the option of just unwrapping all exceptions unconditionally until a handler is found.

In our use case, I don't think this would lead to unwanted behaviours.

[geoand]

After opening the issue, I started to wonder what would be the drawback of also optionally providing the option of just unwrapping all exceptions unconditionally until a handler is found.

Although this might make sense, it is however not how the JAX-RS / Jakarta REST specifies things, so it's best not to make this the default behavior.