From: nobu.nokada@... Date: 2002-05-10T07:59:23+09:00 Subject: Re: timeout.rb problem Hi, At Fri, 10 May 2002 06:56:16 +0900, Nikodemus Siivola wrote: > The scripts below prints out "achived enlightenment, exiting > gracefully...", which is in this context quite understandable -- but > extremely surprising if the inner timeout is "more distant", in a library > module for example. You can use particular exception classes. > #!/usr/bin/ruby > > require 'timeout' > > def meditate > begin to = Class.new(TimeoutError) timeout(10, to) { loop { self.inspect } } rescue to > puts "achived enlightenment, exiting gracefully..." > exit > end > end > > def try_to_meditate > begin to = Class.new(TimeoutError) timeout(1, to) { meditate } rescue to > puts "meditation takes too long, rush to abort!" > abort > end > end > > try_to_meditate > > __END__ > - Is this technically correct? Should a rescue block rescue > an exception that is raised from outside of it's scope? Yes, that's exception. > - Is this really the way timeout's should behave? Maybe TimeoutError > could contain information of it's nesting level so that when > rescuing a timeout one could reraise it so that the higher level > code would have a chance to rescue it too... Like this? Index: timeout.rb =================================================================== RCS file: /cvs/ruby/src/ruby/lib/timeout.rb,v retrieving revision 1.10 diff -u -2 -p -r1.10 timeout.rb --- timeout.rb 2002/01/16 03:36:32 1.10 +++ timeout.rb 2002/05/09 22:53:52 @@ -27,8 +27,11 @@ class TimeoutError e + raise if exc + raise TimeoutError, e.message, e.backtrace ensure y.kill if y and y.alive? -- Nobu Nakada