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...
Cheers, Sergey
>
> On 11/2/2012 7:21 AM, Marek Potociar wrote:
>> Hi Sergey,
>>
>> Obviously, I did not give it enough thought. What you're writing makes
>> a lot of sense. So I'm changing my cautious "0/+1" to clear "-1" on
>> the suggested improvement.
>>
>> Marek
>>
>> On Nov 2, 2012, at 11:58 AM, Sergey Beryozkin <sberyozkin_at_talend.com>
>> wrote:
>>
>>> On 02/11/12 10:47, Marek Potociar wrote:
>>>> Hello experts,
>>>>
>>>> For full context, please check out the proposal from Bill Burke:
>>>> http://java.net/jira/browse/JAX_RS_SPEC-257
>>>>
>>>> While I still need to think about this a little bit more, off the
>>>> top of
>>>> my head it seems like an interesting idea to me: We may perhaps be able
>>>> to consolidate the ClientException and MessageProcessingException to a
>>>> single ProcessingException that would be used on both, client and
>>>> server, not only in case of filter/interceptor failures but also in all
>>>> cases where ClientException has been used before (any client errors).
>>>>
>>>
>>> I really like the current approach where ClientException represents
>>> all the errors which happened at the client side, where
>>> MessageProcessingException acts as a cause exception
>>> (ClientException.getCauseException()) in case of read/input
>>> processing errors.
>>>
>>> Having MessageProcessingException representing a client send error on
>>> the client side would also be confusing IMHO.
>>>
>>> On the server side, MessageProcessingException has to be mapped
>>> either to 400 or 500, depending on where it has occurred, so to be
>>> honest I do not see much benefit in unifying ClientException &
>>> MessageProcessingException.
>>>
>>>> One reservation I had is that it would be a bit harder to distinguish
>>>> where did the error came from. But it does not seem to be such a big
>>>> deal...
>>>>
>>>
>>> I think
>>> try {
>>> client.get();
>>> } catch (ClientException ex) {
>>> if (ex.getCause() instanceof MessageProcessingException) {
>>> // read or write error
>>> } else {
>>> // connection issue...
>>> }
>>> } catch (WebApplicationException ex) {
>>> // error from the server
>>> }
>>>
>>> Looks OK
>>>
>>> Cheers, Sergey
>>>
>>>> In any case, I'm looking forward to your feedback.
>>>>
>>>> Thanks,
>>>> Marek
>>>
>>>
>>
>