hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Sutton <adr...@intencha.com>
Subject Re: DO NOT REPLY [Bug 19868] - Need the InterruptedIOException when timeout
Date Fri, 16 May 2003 07:48:03 GMT
My non-binding vote would be as a +0 as well, I like the concept of the  
patch, I'd probably just simplify it for this release (ie: just make  
the nested exception available, but not worry about printing it's stack  
trace or any of the extra lang stuff), then if desired add lang as a  
dependency for 2.1 (though I don't like adding dependencies).

Regards,

Adrian Sutton.

On Friday, May 16, 2003, at 02:42  PM, Jeffrey Dever wrote:

> I guess we need a vote.   Please vote on including this patch for the  
> 2.0 beta release.
>
>
> Michael Becke wrote:
>
>> In general exception handling could use some work.  One problem in  
>> particular is that all HttpClient exceptions are subclasses of  
>> URIException.  I'm not sure how this one started, but it's strange.
>>
>> I also agree that there is not a strict convention about what is  
>> re-thrown, buried and or logged.  This patch does not really attempt  
>> to change any of these problems.  It's only purpose is to provide  
>> more information about the cause of exceptions at the user level.   
>> The user can choose to do whatever they want with the exceptions.   
>> The example you gave is one possible use.  I imagine that it would  
>> also be useful for logging method failures.  Currently one would have  
>> to search through the log for the original cause of an exception.
>>
>> If we would like to wait until 2.1 to perhaps include Lang and  
>> reorganize exceptions that's okay with me.  I don't see much harm in  
>> adding support for nested exceptions now though, assuming that we  
>> want to do it eventually.
>>
>> Mike
>>
>> Jandalf wrote:
>>
>>> The SomeOtherGawdAwefulException was just an example of continuing  
>>> the idea to have another Exception type possibly contained in the  
>>> ChainedException class.  We are not going through all this work just  
>>> because there will only ever be one chained exception, IIOE, right?
>>>
>>> I'm not against exception chaining, but we are taliking about  
>>> changing the semantics of the exception handling for the sake of  
>>> exposing another exception type while preserving the interface.  It  
>>> just does not feel good over here; it does not seem fully motivated.
>>>
>>> Thinking about this a bit more, we really do not have any "Exception  
>>> rules" for exceptions thrown out to user code.  We just have some  
>>> casual conventions that determine which exceptions are thrown out,  
>>> which are converted to HttpClient types and which are swallowed.
>>>
>>>
>>>
>>> bugzilla@apache.org wrote:
>>>
>>>> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED  
>>>> COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
>>>> <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19868>.
>>>> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED  
>>>> IN THE BUG DATABASE.
>>>>
>>>> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19868
>>>>
>>>> Need the InterruptedIOException when timeout
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------- Additional Comments From olegk@apache.org  2003-05-14 19:37  
>>>> -------
>>>> Actually I do not. The problem is that HttpClient#executeMethod may  
>>>> not throw
>>>> SomeOtherGawdAwefulException (unless it's a runtime exception or a  
>>>> sub class of
>>>> either IOException or HttpException). The only way to get hold of  
>>>> the original
>>>> exception along with all its properties is to chain it. The  
>>>> alternative would be
>>>> to implement all the possible exception types as sub classes of  
>>>> HttpException,
>>>> which is in my opinion is as ugly. Exception chaining is the most  
>>>> flexible way
>>>> of dealing with heterogeneous exceptions, and flexibility usually  
>>>> carries a
>>>> price tag.
>>>> Oleg
>>>>
>>>> -------------------------------------------------------------------- 
>>>> -
>>>> To unsubscribe, e-mail:  
>>>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>>> For additional commands, e-mail:  
>>>> commons-httpclient-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:  
>>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail:  
>>> commons-httpclient-dev-help@jakarta.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:  
>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:  
>> commons-httpclient-dev-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> 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