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 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:
Drop ClientException
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.
Make MessageProcessingException a subclass of ProcessingException
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?
Marek
On Nov 2, 2012, at 4:06 PM, Bill Burke <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