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

From: Bill Burke <>
Date: Fri, 02 Nov 2012 09:53:57 -0400

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.

Bill Burke
JBoss, a division of Red Hat