hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject [Proposal] exception handling revised
Date Fri, 04 Jul 2003 19:52:14 GMT
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)

- Why on earth does HttpException have to extend URIException? That's
just lunacy on a massive scale.

- HttpClient#excecuteMethod & HttpMethodBase#execute declare but never
throw IOException


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
 - 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

Cheers

Oleg


Mime
View raw message