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 [EMAIL PROTECTED]  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.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to