ExceptionMappers are custom, application provided, components that can catch thrown application exceptions and write specific HTTP responses. They are classes annotated with @Provider and that implement this interface

         package javax.ws.rs.ext;

         import javax.ws.rs.core.Response;

         /**
         * Contract for a provider that maps Java exceptions to
         * {@link javax.ws.rs.core.Response}. An implementation of this interface must
         * be annotated with {@link Provider}.
         *
         * @see Provider
         * @see javax.ws.rs.core.Response
         */
         public interface ExceptionMapper<E>
         {
            /**
            * Map an exception to a {@link javax.ws.rs.core.Response}.
            *
            * @param exception the exception to map to a response
            * @return a response mapped from the supplied exception
            */
            Response toResponse(E exception);
         }
      

When an application exception is thrown it will be caught by the JAX-RS runtime. JAX-RS will then scan registered ExceptionMappers to see which one support marshalling the exception type thrown. Here is an example of ExceptionMapper

         @Provider
         public class EJBExceptionMapper implements ExceptionMapper<javax.ejb.EJBException>
         {
            public Response toResponse(EJBException exception) {
               return Response.status(500).build();
            }
         }
      

You register ExceptionMappers the same way you do MessageBodyReader/Writers. By scanning for @Provider annotated classes, or programmatically through the ResteasyProviderFactory class.

RESTEasy has a set of built-in exceptions that are thrown by it when it encounters errors during dispatching or marshalling. They all revolve around specific HTTP error codes. You can find them in RESTEasy's javadoc under the package org.jboss.resteasy.spi. Here's a list of them:

Suppose a client at local.com calls the following resource method:

   @GET
   @Path("remote")
   public String remote() throws Exception {
      Client client = ClientBuilder.newClient();
      return client.target("http://third.party.com/exception").request().get(String.class);
   }
   

If the call to http://third.party.com returns a status code 3xx, 4xx, or 5xx, then the Client is obliged by the JAX-RS specification to throw a WebApplicationException. Moreover, if the WebApplicationException contains a Response, which it normally would in RESTEasy, the server runtime is obliged by the JAX-RS specification to return that Response. As a result, information from the server at third.party.com, e.g., headers and body, will get sent back to local.com. The problem is that that information could be, at best, meaningless to the client and, at worst, a security breach.

RESTEasy has a solution that works around the problem and still conforms to the JAX-RS specification. In particular, for each WebApplicationException it defines a new subclass:

WebApplicationException
+-ResteasyWebApplicationException
+-ClientErrorException
| +-ResteasyClientErrorException
| +-BadRequestException
| | +-ResteasyBadRequestException
| +-ForbiddenException
| | +-ResteasyForbiddenException
| +-NotAcceptableException
| | +-ResteasyNotAcceptableException
| +-NotAllowedException
| | +-ResteasyNotAllowedException
| +-NotAuthorizedException
| | +-ResteasyNotAuthorizedException
| +-NotFoundException
| | +-ResteasyNotFoundException
| +-NotSupportedException
| | +-ResteasyNotSupportedException
+-RedirectionException
| +-ResteasyRedirectionException
+-ServerErrorException
| +-ResteasyServerErrorException
| +-InternalServerErrorException
| | +-ResteasyInternalServerErrorException
| +-ServiceUnavailableException
| | +-ResteasyServiceUnavailableException

The new Exceptions play the same role as the original ones, but RESTEasy treats them slightly differently. When a Client detects that it is running in the context of a resource method, it will throw one of the new Exceptions. However, instead of storing the original Response, it stores a "sanitized" version of the Response, in which only the status and the Allow and Content-Type headers are preserved. The original WebApplicationException, and therefore the original Response, can be accessed in one of two ways:

// Create a NotAcceptableException.
NotAcceptableException nae = new NotAcceptableException(Response.status(406).entity("ooops").build());

// Wrap the NotAcceptableException in a ResteasyNotAcceptableException.
ResteasyNotAcceptableException rnae = (ResteasyNotAcceptableException) WebApplicationExceptionWrapper.wrap(nae);

// Extract the original NotAcceptableException using instance method.
NotAcceptableException nae2 = rnae.unwrap();
Assert.assertEquals(nae, nae2);

// Extract the original NotAcceptableException using class method.
NotAcceptableException nae3 = (NotAcceptableException) WebApplicationExceptionWrapper.unwrap(nae); // second way
Assert.assertEquals(nae, nae3);
   

Note that this change is intended to introduce a safe default behavior in the case that the Exception generated by the remote call is allowed to make its way up to the server runtime. It is considered a good practice, though, to catch the Exception and treat it in some appropriate manner:

   @GET
   @Path("remote/{i}")
   public String remote(@PathParam("i") String i) throws Exception {
      Client client = ClientBuilder.newClient();
      try {
         return client.target("http://remote.com/exception/" + i).request().get(String.class);
      } catch (WebApplicationException wae) {
         ...
      }
   }

Note. While RESTEasy will default to the new, safer behavior, the original behavior can be restored by setting the configuration parameter "resteasy.original.webapplicationexception.behavior" to "true".

You may override RESTEasy built-in exceptions by writing an ExceptionMapper for the exception. For that matter, you can write an ExceptionMapper for any thrown exception including WebApplicationException