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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
