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 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
