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