Without the default exception mapper, the entity of WebApplicationException is always null #46875
Description
Describe the bug
Without the default exception mapper, the entity of WebApplicationException is always null
While the Quarkus documentation [1] advertises that disabling the default exception mapper is useful in some instances, the documentation does not mention that the error handlers for REST client methods returning regular objects can regress, because the WebApplicationException no longer has an entity.
As a result, any error handlers for REST client method that returns "a regular object" will no longer be able to read the error response.
Secondarily, this behavior does not allow to mix Uni<jakarta.ws.rs.core.Response> and Uni<Payload> return types on REST client methods.
If the default exception mapper was active, we would get WebApplicationExceptions for the Response case.
If the default exception mapper was inactive, the error handlers of Uni<Payload> cannot pull the response body from non-2xx responses.
[1] https://quarkus.io/guides/rest-client#disabling-the-default-mapper
Expected behavior
Independent of the default exception mapper, developers have the expectation that when their code catches a WebApplicationException in a REST client, exception.getResponse().readEntity(String.class) returns the textual response body.
Actual behavior
exception.getResponse().readEntity(String.class) returns null rather than the textual response body.
The class of the response is org.jboss.resteasy.reactive.client.api.WebClientApplicationException$DummyResponse, a response implementation with hard-coded return values.
How to Reproduce?
Reproducer: https://github.com/f4lco/quarkus-reproducer-null-entity
Steps to reproduce:
./mvnw quarkus:devhttp :8080/hello
Expected output:
HTTP status '500', and my error message was 'world'
Actual output:
HTTP status '500', and my error message was 'null'
Output of uname -a or ver
Darwin xxx 22.6.0 Darwin Kernel Version 22.6.0: Thu Dec 5 23:45:11 PST 2024; root:xnu-8796.141.3.709.7~4/RELEASE_X86_64 x86_64
Output of java -version
java version "17.0.1" 2021-10-19 LTS Java(TM) SE Runtime Environment (build 17.0.1+12-LTS-39) Java HotSpot(TM) 64-Bit Server VM (build 17.0.1+12-LTS-39, mixed mode, sharing)
Quarkus version or git rev
3.19.3
Build tool (ie. output of mvnw --version or gradlew --version)
Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)
Additional information
If this behavior is not a bug, or if this behavior is a wontfix, I would hope the Quarkus documentation mentioned this pitfall.
Disabling the default exception mapper does not only change the behavior for REST client methods returning Uni<Response>, but also changes the behavior of methods returning Uni<Payload> in a very surprising way.
As it stands, Quarkus REST requires the entire service to stick to Uni<Response>, or Uni<Payload>, (mutually exclusive) to enable predictable and correct error handling.