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