On 02/11/12 18:51, Marek Potociar wrote:
>
> On Nov 2, 2012, at 6:13 PM, Sergey Beryozkin<sberyozkin_at_talend.com> 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?
>
Sounds like a good idea. I'm just sensing something is not right. Purely
refactoring wise it is spot on. I think there has to be construct there
dedicated to representing "client" centric exceptions.
We are going to lose it...
Sergey
> 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_at_redhat.com
>>> <mailto:bburke_at_redhat.com>> 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
>>>
>>
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com