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.
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
>>
>>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com