hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
Subject Re: [Proposal] exception handling revised
Date Mon, 07 Jul 2003 13:53:34 GMT
As an addendum to my previous email, it would also be possible to use 
Oleg's #2 option and just change HttpException to extend IOException. 
This would also allow us to keep API compatability.  If this was done we 
could remove the throws IOException from HttpClient.executeMethod().

Mike

Michael Becke wrote:
> Oleg Kalnichevski wrote:
> 
>> One of the major shortcomings of the existing architecture is unclear
>> and convoluted exception handling framework.
>> Here's the list of my personal gripes with it
>>
>> - there is no clear-cut distinction between protocol exceptions (that
>> are in most cases fatal) and transport exception (that are in most cases
>> recoverable). As a result possible recovery strategy is not clear (at
>> least to me)
> 
> 
> Quite so.  I would be wary about trying to recover from an exception 
> with the current configuration.  As a user currently, the only safe 
> assumtion is that all exceptions are fatal.
> 
>> - Why on earth does HttpException have to extend URIException? That's
>> just lunacy on a massive scale.
> 
> 
> This one has always confused me as well.  It probably made some sense at 
> the time.
> 
>> - HttpClient#excecuteMethod & HttpMethodBase#execute declare but never
>> throw IOException
> 
> 
> I think this is just to get around throwing a URIException explicitly... 
> maybe:)
> 
>>
>> I personally see two ways of fixing things
>>
>> 1) "Back to the roots" -------------------------
>> This approach is basically about going back to a very simple, but clear
>> framework that existed before but got messed up on the way toward
>> beta-1.
>>  org.apache.commons.httpclient.HttpException (Root protocol exception)
>>   |
>>   +-- org.apache.commons.httpclient.cookie.MalformedCookieException
>>   |
>>   +-- org.apache.commons.httpclient.auth.AuthenticationException
>>   |
>>   +-- ...
>>
>>  java.io.IOException (Root transport exception;   |                   
>> all i/o exceptions considered recoverable. Period)
>>   |
>>   +-- java.io.InterruptedIOException (timeout)
>>   |
>>   +-- ...
>>
>> Pros:
>>  - simplicity
>>  - no need to 'warp' or 'chain' exceptions. No need for Commons-lang
>> Cons:
>>  - Some i/o exceptions MIGHT be unrecoverable, but at the moment I can't
>> think of a single one
> 
> 
> I think the one case is when an IO exception occurs after content has 
> been posted.  This is what the MethodRetryHandler was created to handle.
> 
>>  - It may not be apparent to everyone that a request that has caused an
>> IOException can be retired
>>
>>
>> 2) Go elaborate
>> -----------------
>>  org.apache.commons.lang.exception.NestableException (or equivalent)
>>   |
>>   +-- org.apache.commons.httpclient.HttpException (Root exception)
>>     |
>>     +-- ...httpclient.HttpProtocolException (Root protocol exception)
>>     |  |
>>     |  +-- ...httpclient.cookie.MalformedCookieException
>>     |  |
>>     |  +-- ...httpclient.auth.AuthenticationException
>>     |  |
>>     |  +-- ...
>>     |
>>     +-- ...httpclient.HttpTransportException        |   (should 'wrap' 
>> java.io.IOException)
>>        |
>>        +-- ...httpclient.RecoverableHttpException
>>        |  |
>>        |  +-- ...httpclient.TimeoutHttpException
>>        |     |
>>        |     +-- ...httpclient.ConnectTimeoutHttpException
>>        |     |
>>        |     +-- ...httpclient.IOTimeoutHttpException
>>        |
>>        +-- ...httpclient.InterruptedHttpException
>>
>> Pros:
>>  - flexibility
>>  - clarity
>> Cons:
>>  - complexity
>>  - most likely requires an external dependency
>> In my opinion we MUST get exception handling right before we do anything
>> else. Exception handling is a foundation of any flexible architecture.
>> I personally can live with either of these two approaches. If you see
>> other alternatives, please share your ideas
> 
> 
> Here's a third option, one that would keep API compatability I think:
> 
> java.io.IOException
>  |
>  +-- org.apache.commons.httpclient.HttpException (Root protocol
>  |   |            exception, also supports nestable exceptions via
>  |   |            Lang or our own custom method)
>  |   |
>  |   +-- org.apache.commons.httpclient.cookie.MalformedCookieException
>  |   |
>  |   +-- org.apache.commons.httpclient.auth.AuthenticationException
>  |   |
>  |   +-- ...
>  |
>  |
>  +-- java.io.InterruptedIOException (timeout)
>  |
>  +-- ...
> 
> This would allow compatibility with people who are currently doing the 
> following:
> 
> try {
> 
>   client.executeMethod(someMethod);
> 
> } catch (IOException e) {
>     // some stuff
> }
> 
> Mike
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: 
> commons-httpclient-dev-help@jakarta.apache.org
> 


Mime
View raw message