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:09 ------- Laura, I'll just throw some ideas at you, but I am not 100% sure that what I am about to suggest is feasible. So, take it with a grain of salt. > 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. I whole-heartedly agree. All IOExceptions should be wrapped in HttpTransportException, otherwise the whole exercise does not make sense in the very first place. In the future (3.0 release) we might even think about changing the super class of HttpException from IOException to Exception and completely doing away with IOExceptions in HttpClient#execute & HttpMethod#execute methods. The overall philosophy should be as simple as that: * HttpProtocolException: Something is wrong on the server side. Contact administrator of the target HTTP server. * HttpTransportException: If HttpRecoverableException, simply retry. If not, contact network administrator. > 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: Here's my plan: * HttpMethodBase deals ONLY with HttpExceptions. All protected and private methods that currently throw IOExceptions will have to be changed to throw HttpTransportException instead. All public methods that declare IOException in their 'throws' clause would remain unchanged BUT in fact would not throw IOException. That should take care of the API compatibility issue. * HttpConnection catches ALL IOExceptions and re-throws them as HttpTransportException This approach is simple, and I personally like the beauty of simplicity (at least when it comes to software engineering) > - 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. I am not concerned about it at all. They can still do it like that. try { HttpClient.executeMethod(...); } catch (IOException ex) { System.out.println("Oopsie..."); System.exit(1); } > Does this all make sense? I'm scared to make this big a change without lots of > feedback from other developers and from clients. I suggest that we should not be doing it in one giant leap. Let's fix things in a series of shorter dashes. Let's commit what you have got so far (once it is approved by Mike), and then we can move on to fixing the internals. I have got to hit the sack. It's Monday here already. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
