Re: Timeout::Error

Charles Oliver Nutter wrote:
> 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
> 

  We use Timeout frequently for computations that we explicitly want to
stop after a specific amount of time; we have hard timing constraints.
If we can't compute it in time, we need to decide on a different course
of action.

  Since Timeout exceptions are an explicit and expected part of a
program's behavior, it makes sense to distinguish them from typically
unexpected errors (i.e. StandardError).  The net libraries should
probably be fixed rethrow its own Timeouts into some API-specific
subclass of Exception.  The only thing that is "exceptional" about
Timeout errors is the delivery mechanism.

  It's a good idea for general-purpose libraries like net/* to have
hooks into a top-level event loop manager (via select()).  But removing
the Timeout mechanism, would be a disaster for encapsulation and
programmer's efficiency.  Having to use a globally-defined callback
(like C's signal(SIGALRM)/alarm()) is far more painful than the
thread-safe ruby Timeout delivery mechanism.

If irb is not trapping Timeout, it's broken,
APIs that leak Timeouts are broken,
Ruby is not broken.

http://kurtstephens.com

P.S.: Restartable exceptions would be a great feature for Ruby.