From: Robert Klemme <bob.news@...>
Date: 2005-11-03T20:27:08+09:00
Subject: Re: Trapping errors.

Hugh Sasse wrote:
> On Thu, 3 Nov 2005, Robert Klemme wrote:
>
>> Hugh Sasse wrote:
>>> On Thu, 3 Nov 2005, Robert Klemme wrote:
>>>
>>>> Hugh Sasse <hgs@dmu.ac.uk> wrote:
>         [...]
>>>>> Then it's already caught, and I should never see the error.
>>>>
>>>> Why not?  If it's printed in the other rescue clause you would see
>>>> it.  Or am I missing something here?
>>>
>>> I wouldn't see it as an error which kills my program.  It would have
>>> been caught, and dealt with, or caught and re-raised, in which case
>>> the outer block would catch it.
>>
>> Well, there's at least the theoretical chance that this block just
>> calls #exit... :-)
>
> It died with a stack trace.  exit doesn't do that.

Yes, but it's not too difficult to print a stack trace like the one you
see when the interpreter writs it.

>>> 1 We have established that a begin...rescue...end block
>>>   will rescue any errors raised inside it, provided the rescue
>>>   clause matches that error type.
>>>
>>> 2 We have established that if a begin ... rescue ... raise ... end
>>>   block re-raises an error, it can be caught by a surrounding
>>>   begin...rescue...end block
>>>
>>> 3 My case is that I have a
>>>    begin
>>>       part1
>>>    rescue Exception, SystemCallError, Errno::EACCES, Errno::EBUSY
>>>       => e part2
>>>    end
>>>
>>>   block and it is not catching a Errno::EBUSY error from part1: The
>>>   error crashes the program.  So:
>>>     If that error has been raised in part1, and not caught in part1
>>>       then I should be able to catch it.
>>>     If that error has been raised in part1, and caught in part1,
>>>       part2 should never come into play, and the program should
>>>       continue
>>>
>>> 4 How can a subclass of Exception not be caught by Exception?
>>> 5 Why doesn't SystemCallError catch it?
>>> 6 Why doesn't the Errno::%s form catch it?
>>>
>>> i.e everything between "Exception" and " =>" should be unnecessary,
>>> but even with those it doesn't catch the error.
>>
>> This sounds really strange.  Here's what I'd do: use set_trace_func
>> to write out all method invocations, returns and thread ids and try
>> to see where it goes.  HTH
>
> Good job I tried to add docs to profiler.rb in stdlib yesterday.
> I'll have a go at that.  I've not played with set_trace_func before,
> so it should be interesting.

This should get you started:

set_trace_func lambda {|event, file, line, id, binding, classname|
  $stderr.printf "th %10d: %-10s %s: %d\n", Thread.current.object_id,
event, file, line if
    /call|return/ =~ event
}

Good luck!

    robert