[Mono-list] exceptions and ECMA issues

[Paolo Molaro]

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.
It says:

--snip snip--
*  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 
exception variable. 
		*  Control is transferred to the matching catch block. [1]
		*  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. [2]
			o Control is transferred to the end point of the try statement. 
--snip snip--

Basically it says that if an exception id thrown, control is transfered to the
matching catch block [1] and only later to the finally block [2].
Partition I, instead, claims that a matching catch block is searched, but
before executing it, control is transfered to the finally block
(section 11.4.2.2.):

--snip snip--
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. 
--snip snip--

I implemented what is specced out in Partition I, hope the ECMA folks can clarify
this issue.

lupus

-- 
-----------------------------------------------------------------
lupus@debian.org                                     debian/rules
lupus@ximian.com                             Monkeys do it better