Skip to main content

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: 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: Re: Re: Ad JAX_RS_SPEC-257: Unification of MessageProcessingException and ClientException
  • Date: Fri, 2 Nov 2012 11:51:40 -0700 (PDT)


On Nov 2, 2012, at 6:13 PM, Sergey Beryozkin <sberyozkin@...> wrote:

> Hi
> On 02/11/12 16:36, Marek Potociar wrote:
>> I'm still not sure what's the big picture in your proposal:
>
>> - You indicated earlier that we should drop ClientException, now you're
>> adding new ClientException subtypes.
>> - ResponseProcessingException seems like something that should be better
>> derived from MessageProcessingException, but you're again using
>> ClientException
>
>> Also, why should we create new connection-related exceptions if Java SE
>> already providers a hierarchy of IOException subclasses in java.net
>> <http://java.net> package that cover these failures (ConnectException,
>> UnknownHostException, NoRouteToHostException, HttpRetryException...)?
>
>> It seems to me that, if we really want to do anything about improving
>> the current processing exception hierarchy, we could do e.g. this:
>
>> 1. Drop ClientException
>> 2. Define a common ProcessingException instead and update client APIs
>>    to throw ProcessingException
>>      * On client side this exception would wrap any exceptions not
>>        related to message processing in filters or interceptors,
>>        including IOExceptions thrown by the transport layer or MBR/MBW.
>> 3. Make MessageProcessingException a subclass of ProcessingException
>> 4. Add new client-side ResponseProcessingException subclass of
>>    MessageProcessingException
>
>> I know we did not get rid of getCause() in case of IOExceptions, but I
>> it still seems to address most of the other issues you had (wrapping
>> filter/interceptor exceptions, missing response processing exception).
>> Would that work for you? Sergey, others would that work for you too?
>
> 
> I just like the expression "ClientException". What does this proposal 
> improve on the server side of things ? I think I'm more comfortable with 
> the latest proposal from Bill, but I'd like a single catch for 
> "ClientException" be sufficient, at the bare level, with respect to 
> managing client-centric exception of all sorts

You could have a single try-catch for a ProcessingException. That would fully 
cover what ClientException covers and additionally remove the need to invoke 
getCause for addressing message processing exception sub-types. Additionally, 
that would also cover exception thrown from Response.readEntity().

Isn't that worth considering? 

Marek

> 
> Or just leave things as they are now, I know Bill is not comfortable with 
> ClientException.getCause() but given Response.readEntity(MyClass.class) 
> will throw MessageProcessingException, clientException.getCause() in case 
> of myClient.get(MyClass.class) seems if not perfect but reasonable IMHO
> 
> Sergey
> 
> 
> 
> 
> 
>> Marek
>
>> On Nov 2, 2012, at 4:06 PM, Bill Burke <bburke@...
>> <mailto:bburke@...>> wrote:
>
>>> 
>>> 
>>> On 11/2/2012 10:28 AM, Marek Potociar wrote:
>>>> Bill,
>>>> 
>>>> You lost me.
>>>> 
>>> 
>>> Eh, maybe some of my ideas aren't that thought out, but.... Consider
>>> this scenario:
>>> 
>>> what do you do when there is response filter/interceptor/MBR failures?
>>> i.e.
>>> 
>>> Order order = target.request().post(Order.class, entity);
>>> 
>>> What if the server returns 200, and a response filter, interceptor or
>>> MBR fails? The client app might want to know a 200 was sent back. As,
>>> server-side, the operation is still successful.
>>> 
>>> So don't we need an exception like this?
>>> 
>>> // thrown if response filter or MBR or interceptor fails
>>> class ResponseProcessingException extends ClientException {
>>> 
>>> Response getResponse() {...}
>>> }
>>> 
>>> readEntity() should probably still throw MessageProcessingException
>>> 
>>> Might also want to have:
>>> 
>>> // can't send request because of bad IP address, can't connect, etc...
>>> class ClientConnectionFailure extends ClientException {}
>>> 
>>> // thrown if socket times out on a request
>>> class ClientTimeout extends ClientException {}
>>> 
>>> 
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>
> 
> 



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

(continued)

[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

[jsr339-experts] Re: [jax-rs-spec users] Re: 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: 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: 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: 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: Re: Re: Ad JAX_RS_SPEC-257: Unification of MessageProcessingException and ClientException

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