On Mon, 2008-05-26 at 20:00 -0400, Sam Berlin wrote:
> >Exception handling is one of those. We cannot make everyone happy.
>
> I think in this case it might actually be possible to appease most
> people. I agree with Oleg that the separation between HttpException &
> IOException is useful, especially considering that the core goes out
> of its way to keep the distinction. With an IOException it's expected
> that the connection just can't be reused, whereas with an
> HttpException there was just some sort of protocol problem, and it's
> possible to recover (not that a recovery is always attempted, but it's
> likely possible). However, I also agree with Jens that it's very
> unwieldy to have to catch three different kinds of exceptions when
> using HttpClient, even if it's most basic form.
>
> As a compromise, I propose that HttpClient.execute be changed to throw
> a single exception (and the HttpMethod subclasses change their
> constructors to also throw that exception). This simplifies the use
> of HttpClient considerably (and IMO makes it much simpler for new
> users of the library). Consider the current situation:
>
> try {
> HttpClient client = new DefaultHttpClient();
> HttpGet m = new HttpGet(location);
> HttpResponse response = client.execute(m);
> if(response.getEntity() != null)
> process(response.getEntity().getContent());
> } catch(URISyntaxException x) {
> // abort1
> } catch(HttpException x) {
> // abort2
> } catch(IOException x) {
> // abort3
> }
>
> vs:
>
> try {
> HttpClient client = new DefaultHttpClient();
> HttpGet m = new HttpGet(location);
> HttpResponse response = client.execute(m);
> if(response.getEntity() != null)
> process(response.getEntity().getContent());
> } catch(HttpClientException x) {
> // abort
> }
>
> It's much simpler and avoids the confusion among exceptions. If
> desired, HttpClientException can require a cause is set
> (URISyntaxException, IOException, HttpException, or possibly anything)
> and details can be driven into.
>
> The internals of the code don't have to change (and I don't think they
> should) -- but the one general entry point into the library could be
> easily be simplified and reduce a lot of boilerplate code.
> Considering that HttpClient is designed to take care of the details
> internally (ie, the ConnectionManager decides whether or not
> connections are reused, and internally it takes care of problems with
> requests or responses), I don't think it's terribly necessary to
> expose the distinction between HttpException & IOException on the
> top-level execute method.
>
> Sam
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]
