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
http://bill.burkecentral.com