hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: API review request / HttpException subclass of IOException
Date Mon, 26 May 2008 18:20:53 GMT
On Mon, 2008-05-26 at 19:39 +0200, Jens Wilke wrote:
> Hi all,
> although there is a chance that I am gonna be killed, I would like to address
> the issue about the exception hierarchy again.
> Since I started a new project I make use of the alpha version of http client in 
> various scenarios (proxy forwarder, rpc). Almost everytime my request code looks 
> like this:
> --snip--
> 		HttpGet g;
> 		HttpResponse r;
> 		HttpGet g;
> 		HttpResponse r;
> 		try {
> 			g = new HttpGet(url);
> 			r = httpClient.execute(httpHost, g);
> 		} catch (URISyntaxException e) {
> 			throw new RethrowException(e);
> 		} catch (IOException e) {
> 			throw new RethrowException(e);
> 		} catch (HttpException e) {
> 			throw new RethrowException(e);
> 		}
> --snip--
> If I get one of these exceptions, this means something went deadly wrong und there
> is no way to cure it and react differently to the three exceptions, it least in my
> situation. There may be some useful reaction to one exception in some other scenario,

> however, I think thats rare.
> To simplify things it would be more elegant if HttpException is a subclass of IOException.
> Looking on http client 3 HttpException is a subclass of IOException and one catch was
> sufficient.
> IMHO the HttpException is an IOException in the OO sense, because http is an I/O protocol.


Exception handling has been discussed A LOT in the early days of
HttpClient redesign. The point is I/O exceptions are generally
recoverable, whereas protocol exceptions are not, so, in my opinion,
keeping those two classes distinct is important. 

> Another thing is the URISyntaxException. Making this a top-level exception in the java
> API is also not very clever, but thats the wrong list for this. But looking in the code
> how the URI is used brings me to another point.

I do not mind catching ´╗┐URISyntaxExceptions and re-throwing them as
HttpExceptions. I will happily take a patch for that.

> In the use case above the host is fixed. So what happens internally is that the string
> is parsed to an URI object and than assembled back to form the URI part of the request

> line. This is redundant for that usage, because the given string could be 
> used directly, it contains no host. Maybe this can be optimized? The only problem 
> would be if the  URI is illegal, e.g. it contains spaces. Should the code be robust 
> and give an exception or should it follow the garbage in garbage out principle?

There is just no way around parsing request URIs because we need to
extract the protocol scheme from it or determine that it does not
contain one. Given the protocol scheme we can pick up the corresponding
socket factory. The request URI parsing just seems unavoidable. 

HttpCore on the other hand will take any garbage for a request URI. If
you have some special requirements, consider putting together a custom
HTTP client on top of HttpCore plus low level connection management,
state management and authentication components from HttpClient. ´╗┐At the
end of the day HttpClient is meant to a bunch of reusable components in
the first place. We ship just _one_ of many possible HTTP agent


> I would prefer seeing a path that sends the given URI string transparently to the remote
> server.
> Best,
> Jens

To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message