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 22:47 ------- Laura, Oleg, Mike, et al, Generally I like the way things are sounding with this, but having had a recent experience trying to track down the cause of an exception in Xerces I'm really not so keen on ever seeing a nested exception again - particularly if it's only added for conceptual niceness. In particular, I don't like the idea of wrapping every IOException in a HttpTransportException, instead I would have dropped HttpTransportException and used IOException itself. The few IOExceptions that are recoverable would have to be wrapped in a HttpRecoverableException but the vast majority of exceptions that people would be trying to track down the source of, would be plain ol' unwrapped exceptions. It also seems to fit better with my view on exception handling that you don't wrap exceptions when possible. In essence, an exception is thrown and works its way back up the stack until someone is prepared to deal with it. That doesn't work so well when you consider throwing a different exception as "dealing with it". I don't really mind either way, but I found it incredibly difficult to have to wade through long stack traces *and* work out which exception actually occurred and which was just created because the API didn't allow the original exception to be thrown. In fact, I wound up having to grab the source to Xerces and rewrite parts of it's exception handling to work out what was going on (for the record, it was my fault). Sorry for coming to the party late, I'm happy to be ignored on this and I forfeit all rights to complain. :) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
