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?
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
>>
>
>