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 11:43 ------- I believe Mike's response to Laura should be included into the bug report -------------------------------------------------------------------------- Michael Becke Wrote: Very nice work Laura. Thank you for taking the initiative on this one. Please see the in-lined comments below. > 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, .. Possibly. I could see this extra information as quite useful. My only worry would be that we have too many exception types. > - 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 think we will probably need it but I would say to leave it out for now. We can always add it when the time comes. I think HttpAbortedException is better. > - 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 say lose the Http. It seems a little redundant. No worries about name collision. That's the beauty of packages. > - 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 think we should push the cause all the way up to the HttpException level. Nestable exceptions occur in other places than just IO. Your TODO example of NTLM IllegalBlockSize is a good one. I imagine there will be a few involving URIExceptions as well. I think leaving just getCause() for now is fine. The most important part is getting the hierarchy right. We can add bells and whistles at a later time. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]