HTTPClient::TimeoutError should subclass ::TimeoutError about httpclient HOT 5 CLOSED

This is a pretty serious bug.

from httpclient.

Yes, it's an API change. Timeout::Error (::TimeoutError) should be handled by the code who called Timeout.timeout.

I don't know how we treat this kind of nested timeout...

from httpclient.

There is nothing for httpclient to do except throw a subclass of ::TimeoutError. It doesn't need to know anything about the outer timeout. As stated the proposed change restores old semantics and still allows new code to distinguish between ::TimeoutError and HTTPClient::TimeoutErrors.

Want a unit test to illustrate the issue and the fix?

from httpclient.

I don't want to throw non StandardError from a library. In 1.8, it's not a StandardError.

0% ruby187 -rtimeout -e 'p Timeout::Error.ancestors'
[Timeout::Error, Interrupt, SignalException, Exception, Object, Kernel]
0% ruby -rtimeout -e 'p Timeout::Error.ancestors' 
[Timeout::Error, RuntimeError, StandardError, Exception, Object, Kernel, BasicObject]

So as a CRuby committer hat, I want to find the way to handle this kind of nested timeout.

As a workaround, can you use httpclient's timeout instead of outer one? (I don't think so...)

from httpclient.

I close this issue as "Wont' fix" because it's a "BUG" that introduced incompatible change to API as original reporter stated. But I still am thinking that it's required change (::Timeout::Error == ::TimeoutError must be handled only by timeout library, not by others) so I cannot revert the change (I cannot change ReceiveTimeout, etc. to a subclass of ::TimeoutError.)

Since this API incompatible BUG lasted over 3 years I assume this change was accepted.

from httpclient.