hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 19868] - Exception handling in HttpClient requires redesign
Date Sun, 13 Jul 2003 23:54:38 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19868>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19868

Exception handling in HttpClient requires redesign





------- Additional Comments From adrian@ephox.com  2003-07-13 23:54 -------
Printing out the cause stack trace is a bare minimum for being able to debug, but it is still
really 
difficult to sort through all that mess - particularly if you wind up with a couple of non-fatal

exceptions that build up to a fatal one (for HttpClient that's likely to be connections to
multiple 
servers or retrying the connection).  The output winds up being pages and pages of useless
stack 
traces.

In some cases of course wrapping exceptions makes a lot of sense, I'd just suggest using the

original IOException instead of wrapping it in a TransportException.  If I were to propose
a rule of 
thumb, I would imagine it would be:

BAD:
catch (xxxException e) {
 throw new yyyException(e.getMessage(), e);
}

OKAY:
catch (xxxException e) {
  throw new yyyException("Some informative error message that fits the situation better than
the 
original message", e);
}

So essentially, if the most appropriate/useful exception message is the one that came with
the 
original exception you should just throw the original exception, otherwise wrap the exception
and 
provide a more informative message.

There are obvious cases where that guideline falls down (like the exceptions that can be thrown
by 
JCE in NTLM but the API requires them to be dealt with).

As I said though, it's not a huge issue for me, just something that should be considered when

thinking about how userfriendly our exception policy is.

Thanks for the good work on this - I haven't had time to look into it much but it definitely
feels 
like a much better exception API already.

Mime
View raw message