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 20:04:52 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 laura@lwerner.org  2003-07-13 20:04 -------
> Besides, do we really have to throw plain IOException there?
> I believe it should be rethrown at least as HttpTransportException.

Good question.  Now that the easy part is (almost) done, I was starting to think
about what kinds of exceptions the HttpClient library should through.  Even
though it's a big change, I think we should probably thrown *only* HttpException
and its subclasses (plus RuntimeException subclasses like
IllegalStateException).  If some of the methods still throw raw IOExceptions, it
kind of defeats the purpose of having HttpTransportException in the first place.

The spot where I have misgivings are the methods that currently throw only
IOException.  All of these would have to be wrapped with TransportException. 
(We can probably add a utility method to do the wrapping.)  Even though this is
a pain, it makes the client usage simpler:

try {
  HttpClient.executeMethod(...);
} catch (HttpException ex) {
  // It broke
}

If someone wants to distinguish specific problems, they can do:

try {
  HttpClient.executeMethod(...);
} catch (HttpTransportException ex) {
  // I/O problem.  Tell the sysadmin or whatever.
} catch (HttpProtocolException ex) {
  // Report this to the user
} catch (HttpException ex) {
  // It just plain broke
}

There are a few caveats:
- Existing code will have to be changed.  Most client code currently catches
both HttpException and IOException.  The compiler will now say "IOException is
not thrown in try block" and issue an error or warning (I forget which).  
- The model is slightly complicated: you have to remember to catch HttpException
last, for example.  But I think compilers catch this too.
- There are rather a lot of exception classes, which is both a plus and a minus.
 It's more for a client to learn.  But they're not forced to deal with all of
the exceptions; they can just catch the ones that need special treatment and
then treat all the others as generic HttpExceptions.

Does this all make sense?  I'm scared to make this big a change without lots of
feedback from other developers and from clients.

Mime
View raw message