On Tue, 2008-05-27 at 15:09 -0400, Sam Berlin wrote: > 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 >
I feel uneasy about this change but as said I will not stand in the way especially given the fact quite a few people do not share my concerns. Go ahead and make changes you deem necessary. Probably opening a JIRA and attaching a patch for review would be a prudent way forward. Meanwhile I'll try my best to make sure you get your commit rights in time. If I fail to get hold of Erik, I'll send the account request myself. Cheers, Oleg > -----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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
