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 23:07 ------- >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. Wrapping all exceptions certainly makes things cleaner. Though, to echo Adrian's thoughts, I think we should try to add value when we wrap exceptions. For example I'm not sure wrapping an IOException at HttpConnection.write() adds any valuable information. Also, the input/output streams of HttpConnection will continue to throw IOExceptions. We could certainly remove the subclassing of IOException for 3.0. We should probably make some note of it in the HttpException JavaDocs. > 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 I think places where only IOExceptions are thrown can be replaced with HttpExceptions if necessary. This should not cause API problems. The only issue would be if both an IOException and an HttpException were thrown. This would cause problems, as Laura mentioned, if someone is catching both. > 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 think we're almost ready to go. I would like to wait another day or so to see if others have any comments. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
