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

From: Sergey Beryozkin <>
Date: Fri, 17 Feb 2012 15:55:33 +0000

Hi Marek,

On 17/02/12 11:38, Marek Potociar wrote:
> Bill, Sergey,
> would you be able to work together on providing a concrete proposal for a JAX-RS exception hierarchy to start with? IT
> should cover both, client as well as server side. The goal would be to reuse the existing exceptions as much as possible
> as well as make the exception hierarchy common (for client and server), wherever it is practical.

I think what you suggest is rather different to what I had in mind when
starting the thread in the first place. I'd be happy to work with Bill
:-), but at the moment I'd prefer us focusing on a much smaller task,
i.e, on making sure the client code can get some reasonable support for
figuring out:
- where the exception has occurred (client or server side)
- more information about the server side exception

To that end I've typed some comments, particularly I proposed
introducing ClientWebAplicationException and
ServerWebApplicationException and work with these classes to make them

That is the base support, what do you think about that.

As far as a finer grained hierarchy is concerned...
For now I'm not quite in favor of it.

I can see why writing an ExceptionMapper<NotAcceptableException> is
simpler than a custom ExceptionMapper<WebApplicationException> and
checking the status but I'm not convinced it can offer a complete
'cover' for a user, instead of getting a single base
ExceptionMapper<WebApplicationException> one would need to register
5-7-maybe more mappers to cover all the possible HTTP errors the runtime
may react to.

Exactly the same on the client side. With the finer grained hierarchy
one would need to have a fairly big sequence of catch blocks, with every
individual exception basically offering an 'easy' interpretation of the
HTTP error code.

I can't say I'm against the finer-grained hierarchy, rather I'm a bit
cautious about introducing it at this stage, may be for 2.1...

We'd have something like this for a start:

BaseException (WebApplicationException ?)
| |
| |
ClientWebApplicationException ServerWebApplicationException (both: the
client side)

for a start.

Possibly at the next stage, we can start with introducing some new finer
exceptions directly off the BaseException and get them reusable on both

Thanks, Sergey

> Let us know,
> Marek
> On 02/01/2012 03:46 PM, Bill Burke wrote:
>> On 2/1/12 9:40 AM, Santiago Pericas-Geertsen wrote:
>>> On Feb 1, 2012, at 9:15 AM, Bill Burke wrote:
>>>> On 2/1/12 9:11 AM, Santiago Pericas-Geertsen wrote:
>>>>> On Jan 30, 2012, at 5:48 PM, Sergey Beryozkin wrote:
>>>>>>> MethodNotAllowedException
>>>>>>> BadRequestException
>>>>>>> NotAcceptableException
>>>>>>> InternalServerErrorException
>>>>>>> UnauthorizedException
>>>>>>> UnsupportedMediaTypeException
>>>>>>> NotFoundException
>>>>>>> Finally, these above exceptions would be useful on the server side.
>>>>>>> *NOT* for application code to catch, but rather to write
>>>>>>> ExceptionMappers for. So, Jersey/Resteasy whoever would throw those
>>>>>>> exceptions internally, and applications could write ExceptionMapper for
>>>>>>> those exceptions.
>>>>>>> Resteasy implemented these features on client/server after suggestions
>>>>>>> from users.
>>>>> I'm not sure I follow this. So the framework throws and catches the
>>>>> exception in order to call the user-defined mapper? Can you elaborate?
>>>>> This seems odd …
>>>> I've had the case where users want to handle 404, 405, etc. on their own instead of the JAX-RS container handling
>>>> them automatically. This is especially the case where users want to send specific error formats back to the client.
>>>> That make sense more?
>>>> Also, these exceptions might be thrown on the server side by app code too.
>>> I understand. In fact, the spec states that implementations should generate a WebApplicationException with the
>>> appropriate status code in all those cases (Section 3.7). So the use case should already be covered, but it's not as
>>> convenient as having an exception hierarchy?
>> Exception hierarchy is nice, IMO. Especially on the client side.
>> Bill

Sergey Beryozkin
Talend Community Coders