[Mono-list] exceptions and ECMA issues
Wed, 22 Aug 2001 17:35:40 +0200
On 08/22/01 Nick Drochak wrote:
> > 2) rethrow opcode. It is not clear where the search for an handler
> > should begin after a rethrow: should it start from the beginning,
> > from the last handler found or from the parent method?
> > Consider:
> -- snip code example --
> > Restarting from the beginning will result in an infinite loop,
> > so, what other option should I choose?
> >From the C# Language Spec (sec 8.9.5 The throw statement):
> "When an exception is thrown, control is transferred to the first catch
> clause in an enclosing try statement that can handle the exception. "
Ok, what I missed is that there is a new throw point (at the rethrow
opcode), so I start the search for an handler from that point.
Rethrow should work in the next snapshot.
> The operative word being "enclosing." Control shouldn't transfer to any
> catch block in the same try, it should always propagate outwards.
> There is a excruciatingly detailed process description of exeception
> propagation in section 8.9.5 of the spec. Perhaps that would help?
Actually, section 15.9.10 confuses another issue a bit, I think.
* If an exception is propagated to the try statement during execution of the try block:
o The catch clauses, if any, are examined in order of appearance to locate a suitable handler for the
exception. The first catch clause that specifies the exception type or a base type of the exception type
is considered a match. A general catch clause is considered a match for any exception type. If a
matching catch clause is located:
* If the matching catch clause declares an exception variable, the exception object is assigned to the
* Control is transferred to the matching catch block. 
* When and if control reaches the end point of the catch block:
o If the try statement has a finally block, the finally block is executed. 
o Control is transferred to the end point of the try statement.
Basically it says that if an exception id thrown, control is transfered to the
matching catch block  and only later to the finally block .
Partition I, instead, claims that a matching catch block is searched, but
before executing it, control is transfered to the finally block
If a match is not found in the current method, the calling method is searched, and so on. If no match is found
the CLI will dump a stack trace and abort the program. If a match is found, the CLI walks the stack back to the
point just located, but this time calling the finally and fault handlers. It then starts the corresponding exception
handler. Stack frames are discarded either as this second walk occurs or after the handler completes, depending
on information in the exception handler array entry associated with the handling block.
I implemented what is specced out in Partition I, hope the ECMA folks can clarify
firstname.lastname@example.org Monkeys do it better