users@jax-rs-spec.java.net

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

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Fri, 2 Nov 2012 15:28:28 +0100

Bill,

You lost me.

Can you summarize how your proposal would look like after you have just a common root ProcessingException and ditched ClientException and defined the other ProcessingException subtypes?
Can you also clearly indicate the purpose of each new exception subtype and it's client/server side affinity? Also, please, do not mix WebApplicationException subtypes into this discussion (unless you meant to draw some connection to processing exceptions, which I failed to recognize from your previous email).

Also, I'm not sure what you're proposing to change in MBR, MBW API, when you say these exceptions can be used within MBR, MBW.

(And please, try to keep the exception subtype count to the absolute minimum that you consider still practical for the use cases you have in mind. E.g. I do not see why we should distinguish between reader, writer or filter failures in the spec - to me these all fall into the same category.)

Marek

On Nov 2, 2012, at 1:43 PM, Bill Burke <bburke_at_redhat.com> 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.
>
>
> 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