Skip to content
Advertisement

JAX-RS (jersey implementation) ExceptionMapper aren’t catching ConstraintViolationException

I have an ExceptionMapper as a @Provider for handling all of my exceptions.

So it is obvious that my class implements ExceptionMapper<Throwable> and we as know, all exceptions are extended Throwable somehow.

Now I used jax-rs @NotNull to checking my resources input values to be not null and by some search, I realized it will throw ConstraintViolationException when the annotated field is null.

So I tried to handle it and add some details to response (add some custom json model) in my ExceptionMapper like this:

@Provider
public class AllExceptionMapper implements ExceptionMapper<Throwable> {

    private final Logger logger = LogManager.getLogger(AllExceptionMapper.class);

    @Override
    public Response toResponse(Throwable ex) {
        Response response;
        CustomError error;
        // handle some errors

        else if (ex instanceof ConstraintViolationException) {
             error = new CustomError(
                 324, // predefined error type in our documents
                 "some details"
             );
             response = Response.status(Response.Status.BAD_REQUEST).entity(error).build();
        }

        // handle some other errors

        return response;
    }

}

The problem is this didn’t work but if I would create another exception mapper provider which implements ExceptionMapper<ConstraintViolationException> and handle it there, it works without any problem.

As I said before (and also checked) all exceptions are extended from Throwable class somehow so what am I missing and why it is not working?

……

By didn’t work, I mean it ignores my mapper (the one which implements from ExceptionMapper<Throwable>) and had the normal behavior which is returning the status code 400 with no response payload like there is no mapper at all

Advertisement

Answer

The way the ExceptionMapper is supposed to work, is that you can create a generic ExceptionMapper<Throwable>, which handles all errors. And then you can create more specific ExceptionMappers which handle the more specific errors in another way. All of this in separate classes.

The fact that doing it in a separate class works for you, lets me believe that there’s a more specific ExceptionMapper somewhere, which handles the exception before you can.

The way ExceptionMappers are intended to be used is actually very clean, and also keeps your code clean. Wanting to keep the code in one central place, will result in a giant if

User contributions licensed under: CC BY-SA
10 People found this is helpful
Advertisement