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
Sergey