[jax-rs-spec users] [jsr339-experts] Concerns about the client-side exception hierarchy

From: Sergey Beryozkin <>
Date: Thu, 26 Jan 2012 10:23:17 +0000

Hi All,

IMHO some refactoring would help to make [1] & [2] better represent the
cause of exceptions on the client side.

At the moment [2] is supposed to be thrown whenever some underlying
exception is raised during the invocation.

Effectively we have 4 possible cases:

1. Client fails to find a matching writer for non-empty request payloads
2. Client fails to connect or deliver the request to the server for
whatever reasons
3. Client gets the server-side HTTP error code
4. Client fails to find a reader for non-empty response payloads

We can get filters throwing exceptions too.

I see [2] being a bit too coarse-grained with [1] giving no much info
either. InvocationException docs say it is meant to be thrown whenever a
problem during the request or response occurs which basically means
throw it every time.

I'd propose the following:

- have the base Exception class named InvocationException, 1-4 above are
to do with the current invocation.

- have Client(WebApplication)Exception raised for 1 & 2, 4 and this
exception can in time offer some hints such as with media type can nnot
be matched, why the connection may have failed, etc

- have Server(WebApplication)Exception raised for 3

With this kind of hierarchy it might be easier to imagine the possible

Next, assuming something like this were supported then I'd suggest
reusing WebApplicationException instead of the base InvocationException.
With Response now being client-friendly, WebApplicationException does
seem like a perfect candidate to represent a base fault; though I'd be
happy even without this further optional optimization