Re: Timeout::Error

Jeremy Thurgood wrote:
> Jim Hranicky wrote:
>> Jeremy Thurgood wrote:
>>
>>>> No.  The exception would be rescued inappropriately then.
>>> At the moment it's being /not/ rescued inappropriately. Why should a 
>>> timeout exception (from within the standard libraries!) evade a naked 
>>> "rescue"? The current situation requires me to figure out everythign 
>>> that can possibly time out and add special-case error handling for 
>>> it. Worse than this, irb doesn't catch Timeout::Error and thus kills 
>>> my session (which typically has a bunch of state in it) whenever the 
>>> http server I'm talking to takes a while to respond.
>>
>> While I tend to agree and ran into the same frustration as you, you can
>> specify the type of exception Timeout throws like so:
>>
>>    timeout(5, StandardError) { ... }
>>
>> which seems to do what's desired,
>>
>>      ruby -rtimeout -e 'begin ; timeout(5, StandardError) { while 
>> true; sleep 1; end }; \
>>      rescue; puts "rescued" ; end'
> 
> Sure, if it's my code that's throwing the timeout. net/protocol.rb and 
> net/http.rb aren't mine and I'm hesitant to monkey-patch them to throw 
> different exceptions when I'm also using other libraries which use them.
> 
> A quick grep through /usr/lib/ruby/1.8 shows at least the following 
> files using timeout without specifying a different exception to use:

This is exactly why timeout is a bad idea. Being able to cause the 
calling thread to throw arbitrary exceptions means that all callers to 
all libraries run the risk of having exceptions bubble out they never 
expected. In this case, calling any of the net/* libraries requires the 
caller to also handle timeout errors.

timeout.rb should be abolished, and the net libraries rewritten to use 
select for IO. Other libraries that use timeout should use safer 
mechanisms that don't require the ability to arbitrarily interrupt a 
calling thread.

- Charlie