On 11/2/2012 12:36 PM, 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
>
ResponseProcessingException just seemed very client specific. That's
all. Just throwing things out...sorry for confusion.
> 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...)?
>
Aren't those all checked exceptions? How about a specific connection
exception that wraps these?
class ConnectionException extends MessageProcessingException {
boolean requestSent();
}
covers everything including timeout.
> 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 hate getCause() and wrapping. It makes for a lot of verbose ugly
code. One important thing about client exceptions is that the
application code will want to know if the request was sent or not and
whether the request was successful or not and whether or not they should
retry or not (connection exceptions). I hate the idea of having to dive
into wrapped exceptions to answer those types of questions.
If I can't get any agreement to mitigate wrapping, I still like your
above proposal.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com