Skip to main content

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

  • From: Marek Potociar <marek.potociar@...>
  • To: jsr339-experts@...
  • Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Ad JAX_RS_SPEC-257: Unification of MessageProcessingException and ClientException
  • 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@...> 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@...> 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



[jsr339-experts] Ad JAX_RS_SPEC-257: Unification of MessageProcessingException and ClientException

Marek Potociar 11/02/2012

[jsr339-experts] Re: Ad JAX_RS_SPEC-257: Unification of MessageProcessingException and ClientException

Sergey Beryozkin 11/02/2012

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

Marek Potociar 11/02/2012

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

Bill Burke 11/02/2012

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

Sergey Beryozkin 11/02/2012

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

Bill Burke 11/02/2012

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

Sergey Beryozkin 11/02/2012

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

Marek Potociar 11/02/2012

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

Bill Burke 11/02/2012

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

Marek Potociar 11/02/2012

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

Bill Burke 11/02/2012

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

Sergey Beryozkin 11/02/2012

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

Marek Potociar 11/02/2012

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

Sergey Beryozkin 11/04/2012

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

Marek Potociar 11/04/2012

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

Sergey Beryozkin 11/05/2012

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

Marek Potociar 11/05/2012

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

Sergey Beryozkin 11/05/2012
 
 
Close
loading
Please Confirm
Close