[jax-rs-spec users] [jsr339-experts] Re: Re: Ad JAX_RS_SPEC-257: Unification of MessageProcessingException and ClientException

From: Sergey Beryozkin <>
Date: Fri, 2 Nov 2012 14:04:49 +0000

On 02/11/12 13:53, Bill Burke wrote:
> On 11/2/2012 9:21 AM, Sergey Beryozkin wrote:
>> Hi Bill,
>> On 02/11/12 12:43, Bill Burke wrote:
>>> My specific concern was that client applications had to deal
>>> ClientException *AND* MessageProcessingException. I think earlier
>>> versions of the API used both exceptions in different places within the
>>> API.
>>> IMO, still, clients should only deal with 2 types of exceptiosn:
>>> ClientException and WebApplicationException. In other words, these two
>>> exceptions should be the base classes for an exception hierarchy.
>>> NotFoundException extends WebApplicationException
>>> ConnectionFailure extends ClientException
>>> ClosedConnectionFailure extends ClientException
>>> ReaderFailure extends ClientException
>>> WriterFailure extends ClientException
>>> Now, if you ditch ClientException and have a shared
>>> MessageProcessingException, you can re-use these exception hierarchies
>>> within MBR, MBW, and Reader/WriterInterceptor both on the client and
>>> server side. ***Client code would not have to deal with wrapped
>>> exceptions and could catch them directly.
>>> So, I'm suggesting ditch ClientException and use
>>> MessageProcessingException instead. Build an additional
>>> non-wire/non-response exception hierarchy off of
>>> MessageProcessingException.
>> Having more ClientException subclasses does make sense to me, I recall
>> Marek was also in favor, however I'm not keen on the idea of
>> MessageProcessingException serving as the base exception even for
>> client-centric exceptions...
> Still, I despise the idea of having to call getCause() to check if a
> specific error condition exists. Its just bad design.

Sure. And I don't like the idea of MessageProcessingException
representing client centric exceptions.

How about this. MessageProcessingException is reused on the client and
the server side internally from MBR/MBW, may be interceptors. On the
server it is mapped to an appropriate HTTP error code.

On the client - to one of to be introduced ClientException subclasses.

I wonder, if it were agreed upon, would we really need
MessageProcessingException ? The runtime would be able to react to
whatever the exception is thrown from MBR/MBW/interceptors