RESTEasy ExceptionMapper is not called when using Hibernate Validator on QueryParams

Describe the bug When using Hibernate validator to check query parameters in a RestEasy endpoint the validation error is returned before it could be caught and altered by a custom ExceptionMapper.

Expected behavior ExceptionMapper should catch and be able to override all exception responses in the controller.

Actual behavior The hibernate validation error response is returned to the caller without even calling the ExceptionMapper.

To Reproduce

ExceptionMapper. I’m using “not implemented” as the default exception to be easy to spot in the response.

@Provider
public class ExceptionMapperConfig implements ExceptionMapper<Throwable> {

    @Override
    public Response toResponse(Throwable e) {
        Response.Status status = NOT_IMPLEMENTED;
        // business logic for overriding the status is omitted

        return Response
                .status(status)
                .entity(e.getMessage())
                .type(MediaType.TEXT_PLAIN)
                .build();
    }
}

Case 1: Controller with Hibernate Validator:

    @GET
    @Path("/hello")
    @Produces(MediaType.APPLICATION_JSON)
    public String hello(@QueryParam @NotNull @NotEmpty String hello) {
        return hello;
    }

When calling it without a @QueryParam (violating @NotNull) the default Hibernate response is returned, not calling ExceptionMapper at all:

http :8080/hello

HTTP/1.1 400 Bad Request
Content-Length: 299
Content-Type: application/json
validation-exception: true

{
    "classViolations": [],
    "exception": null,
    "parameterViolations": [
        {
            "constraintType": "PARAMETER",
            "message": "must not be null",
            "path": "hello.hello",
            "value": ""
        },
        {
            "constraintType": "PARAMETER",
            "message": "must not be empty",
            "path": "hello.hello",
            "value": ""
        }
    ],
    "propertyViolations": [],
    "returnValueViolations": []
}

Case 2: Controller without a Hibernate Validator:

    @GET
    @Path("/hello")
    @Produces(MediaType.APPLICATION_JSON)
    public String hello(@QueryParam String hello) {
        throw new RuntimeException("custom exception");
    }

When calling it and running into any exception during execution they will be properly caught and handled by the ExceptionMapper:

http :8080/hello
HTTP/1.1 501 Not Implemented
Content-Length: 16
Content-Type: text/plain;charset=UTF-8

custom exception

Environment (please complete the following information):

• Quarkus 1.7.2.Final
• Maven
• Running in dev-mode UPDATE: the same is true for running a packaged jar. Haven’t tested in native.
• IntelliJ IDEA 2020.2.1

[fxnn]

Unless I am reading this wrong, I am pretty sure what you are seeing is the desired behavior, because JAX-RS will use the ExceptionMapper whose generic type best matches the exception - which is QuarkusRestViolationExceptionMapper in this case (this is JAX-RS spec behavior).

Thank you for the information. Can you please check that? I can’t find anything about that class.

Check what exactly?

The name of the class you mentioned. As my links show, there’s no such class in the Quarkus source code. But meanwhile, I think you meant io.quarkus.hibernate.validator.runtime.jaxrs.ResteasyViolationExceptionMapper, right?

Also, when just getting the 400 response, it’s hard to find out how to change it, so it should be documented – I guess in the validation guide.

I’m not really following here, can you explain?

Sorry. As a developer using Quarkus, when I see that my application returns just the 400 Bad Request created by the ResteasyViolationExceptionMapper, but I want my application to behave differently, I need to find out how to change the behavior, so that I can adapt it to my specific requirements.

However, without googling and finding your hint here on the GitHub issue, it would’ve been hard for me to know that I need to implement a ExceptionMapper<javax.validation.ValidationException>. Therefore, some instructions in the validation guide would be really helpful.

[tlvlp]

@geoand thanks, it makes sense.

What I was trying to achieve is to have a central exception mapper, assuming that it would override all exception mappers, instead of creating a separate class for each exception type and having other handlers working in the background without being clearly visible for whoever has to maintain the code after me.