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 03:02 ------- I'm attaching a preliminary patch for this, following Oleg's proposal on the mailing list. Here are some areas where I'd like feedback: - Is AuthenticationException too broad? Should there be different exceptions for: - Incorrect credentials / password / login / whatever, vs. - Other problem: no such provider, unknown auth type, .. - I added an HttpInterruptedException for cases where client code tells us to abort a transaction. - Should I leave this out until we actually add the abort code? - Should it be called HttpAbortedException instead? Or something else? - I'm starting to wonder if all these classes really need "Http" at the beginning of their names. HttpException definitely does, for compatibility reasons if nothing else. But could the others just be ProtocolException, TransportException, etc? There's a chance for a collision if a Java file uses two different network libraries that both have a ProtocolException, but it doesn't seem to likely. - I added a primitive exception chaining mechanism to HttpTransportException. Right now it wraps any Throwable. Oleg had suggested wrapping just IOException. Any preferences? Also, how fancy does the chaining mechanism need to be? I'm happy with just "getCause()", but if people want me to I could add some of the other exception chain accessors that commons-lang uses in its classes. - I haven't yet gone through and wrapped all of the IOExceptions and SocketExceptions inside HttpTransportException. I want to get the exception hierarchy right first. - I also haven't cleaned up "throws" and "@throws" declarations yet. Here's Oleg's proposal, from an email sent around July 6, 2003. On 7/7/2003 Mike suggested having HttpException extend IOException, which is what I implemented. Oleg wrote: 2) Go elaborate ----------------- org.apache.commons.lang.exception.NestableException (or equivalent) | +-- org.apache.commons.httpclient.HttpException (Root exception) | +-- ...httpclient.HttpProtocolException (Root protocol exception) | | | +-- ...httpclient.cookie.MalformedCookieException | | | +-- ...httpclient.auth.AuthenticationException | | | +-- ... | +-- ...httpclient.HttpTransportException | (should 'wrap' java.io.IOException) | +-- ...httpclient.RecoverableHttpException | | | +-- ...httpclient.TimeoutHttpException | | | +-- ...httpclient.ConnectTimeoutHttpException | | | +-- ...httpclient.IOTimeoutHttpException | +-- ...httpclient.InterruptedHttpException Pros: - flexibility - clarity Cons: - complexity - most likely requires an external dependency In my opinion we MUST get exception handling right before we do anything else. Exception handling is a foundation of any flexible architecture. I personally can live with either of these two approaches. If you see other alternatives, please share your ideas Mike wrote: As an addendum to my previous email, it would also be possible to use Oleg's #2 option and just change HttpException to extend IOException. This would also allow us to keep API compatability. If this was done we could remove the throws IOException from HttpClient.executeMethod(). Oleg replied: Mike's suggestion to extend IOException does seem to be the best option that we have right now. It provides a (relatively) easy migration path for 2.0 users (API compatibility still does not save them from having to rethink their exception handling framework), while giving us enough flexibility to get things done (more or less) right. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
