JAX-RS client: ResponseProcessingException handling

Question

Some overloaded call request methods, such as: get() and post(Entity<?> entity) (there are others) of SyncInvoker return a Response object, rather than the unmarshalled content.

I noticed that in the case of get() , there is no documented ResponseProcessingException , while other methods, such as all 3 overloaded post methods, may throw a ResponseProcessingException .

I'm aware that ResponseProcessingException is a RuntimeException which inherits from ProcessingException , but I still would interpret this to mean that the get() method won't throw a ResponseProcessingException .

Is this correct? What about ClientResponseFilter ? Why is the behavior different than the behavior of the other call request methods ( put , post ,..)?

Also, the Javadoc for the methods which do throw a ResponseProcessingException says:

in case processing of a received HTTP response fails (eg in a filter or during conversion of the response entity data to an instance of a particular Java type).

The part:

or during conversion of the response entity data to an instance of a particular Java type

seems to be wrong here, as the readEntity method should not yet have been called:

https://jersey.java.net/documentation/latest/filters-and-interceptors.html#d0e9915

Is this a copy & paste documentation error?

I guess a filter would be a valid case, though.

Answer 1

The documentation is certainly inconsistent. It's clear that ResponseProcessingException is intended to be thrown when a ClientResponseFilter fails.

The implementation I'm looking at (RESTEasy 3.0.16) does this:

try {
    filter.filter(requestContext, responseContext);
} catch (ResponseProcessingException e) {
    throw e;
} catch (Throwable e) {
    throw new ResponseProcessingException(response, e);
}

There is no reason that the get method would not declare the exception when the put and post methods do. Internally they are all handled by the same code.

My conclusion is that the slight difference in documentation between the methods is just an oversight.

Interestingly, in my copy of the source code, the get() method has this line in its javadoc:

/**
 * @throws javax.ws.rs.ProcessingException
 *          in case the invocation processing has failed.

While all the other similar methods (eg get(Class<T>) ) are documented like this:

/**
 * @throws ProcessingException         in case the request processing or subsequent I/O operation fails.

What catches my eye is the fully qualified class name in the first one. Just a hunch, but that makes me think it was put in at a different time or by a different person. Maybe I'm overanalysing. I tried to look at the revision history, but all I found was a single commit saying "move source code to its own repository"). So much for that.

However, as you pointed out, it's not an error, since ResponseProcessingException is and a subclass of ProcessingException and isn't even a checked exception anyway.

Answer 2

If you don't want your exception wrapped in ResponseProcessingException , you can make your exception extend it, then it will come without wrapping. Of course, this is feasible only if you use your own exception and you are OK with RuntimeException.