On Tue, Oct 23, 2012 at 8:10 AM, ajay paswan <[email protected]> wrote:
>> something like the below would catch errors 1 and 2 respectively, and if
>> the error didn't fall into those categories then the third rescue would
>> catch it.
>>
>> rescue 1
>> rescue 2
>> rescue
>
> but I have seen that in the following two statements
>
> rescue => e
> and
> rescue Exception => e
>
> The 'execution expired' error is caught by second statement, but not
> first statement.. WHY?

We cannot know the type of exception if you do not post it.  One
possible explanation:

irb(main):031:0> begin
irb(main):032:1* raise 'execution expired'
irb(main):033:1> rescue => e
irb(main):034:1> printf "empty: %p\n", e
irb(main):035:1> rescue Exceptin => e
irb(main):036:1> printf "Exception: %p\n", e
irb(main):037:1> end
empty: #<RuntimeError: execution expired>
=> nil
irb(main):038:0> p RuntimeError.ancestors
[RuntimeError, StandardError, Exception, Object, PP::ObjectMixin,
Kernel, BasicObject]
=> [RuntimeError, StandardError, Exception, Object, PP::ObjectMixin,
Kernel, BasicObject]
irb(main):039:0>

Note that a rescue clause causes all exceptions of the declared class
*and subclasses*.  Also handlers are processed from top to bottom and
the first matching handler is used.

Kind regards

robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

-- You received this message because you are subscribed to the Google Groups 
ruby-talk-google group. To post to this group, send email to 
[email protected]. To unsubscribe from this group, send email 
to [email protected]. For more options, visit this 
group at https://groups.google.com/d/forum/ruby-talk-google?hl=en

Reply via email to