hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jandalf <jsde...@apache.org>
Subject Re: DO NOT REPLY [Bug 19868] - Need the InterruptedIOException when timeout
Date Fri, 16 May 2003 16:54:12 GMT
-0.5

Its non-interface effecting, which is good, but the mangitude of the 
changes seem larger than the magnitude of the requirements and does make 
for slightly uglier user code.

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