[Mono-list] exceptions and ECMA issues

Paolo Molaro lupus@debian.org
Wed, 22 Aug 2001 18:59:16 +0200

On 08/22/01 James Perry 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<<<
> >
> > Restarting from the beginning will result in an infinite loop,
> > so, what other option should I choose?
> >
> The sensible solution, IMHO, is to go to the next enclosing try block, not
> the next catch handler.
> First, the specs:
> Part III, 3.23, lines 7-9:
>   ... It throws the same exception that was caught by this handler.
> My interpretation is that this should be treated exactly like a
> traditional throw - catch blocks aren't within protected try blocks so the
> exception should go to the next highest-level try{} block.
> Secondly, the principle of least astonishment:
> If rethrow goes up to the previous method then it will always go to the
> next method - you can get around this behaviour if you want by writing
> type-smart catch handlers, but that's really got to be intended behaviour.
> If rethrow goes to the next catch block for the same try{}, and one of
> your catch handlers wants an interface, you really have no clue where it's
> going to go unless you do a lot of work trying to figure that out.
> rethrowing to the parent method is the least astonishing, so it should be
> the behaviour implemented.

The behavior I implemented is to consider the point where the rethrow
happens the search point for an handler: this seems what is actually intended in
the spec. So, basically, rethrow throws the same exception, but at a
different code position and this code position is what needs to be used to
search the next catch handler to execute.

Thanks for your comments.


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