I personally think that just throwing IOException from execute is the best course of action (and allowing the cause to be retrieved from getCause). I offered HttpClientException as a new type simply because a third exception that isn't IOException or HttpException seemed like a good compromise -- but I agree just having IOException fits much more in-line with how people expect to use HttpClient.
Given that HttpClient really only has one exposed method -- execute(...) -- I do think that changing those methods to just throw IOException is simpler. Consider the change a short while back when we cleaned up abort() to correctly abort waiting-for-connection requests -- that let us drop InterruptedException from the throws list. The result of dropping that exception is a lot of boilerplate exception-handling code got removed, and it brought using HttpClient one step closer to not caring how the internals of it work (which IMO is a good thing). The distinction between an I/O and a protocol exception is a good one -- but not one I think we need to force on users at the HttpClient.execute level. It's definitely imperative within the internals of the API and especially on the HttpCore level. But for people just wanting to execute an http request... if it screwed up, it screwed up. If you really need or want to know why it screwed up, you can dive into it from the exception's cause. Just my $0.02 atleast. Sam -----Original Message----- From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 27, 2008 2:52 PM To: HttpComponents Project Subject: Re: API review request / HttpException subclass of IOException Sam, The trouble is that process of consuming HTTP response content can always result in an I/O exception. For real life applications working directly with the input stream is the only possible way. So, we are still back to two exceptions: IOException & ?HttpClientException, which I do not see as much of an improvement over ?HttpException & IOException. The possibility would be to derive ??HttpClientException from IOException and rethrow all HttpException as ???HttpClientException. Then, we could add the following method to the HttpClient interface HttpResponse executeLookMaNoProtocolExceptions(HttpUriRequest request) throws IOException; or even convert all methods of HttpClient to throw IOExceptions only. I am not very hot on this change but will not stand in your way if you really see this as an improvement. Cheers Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
