[Mono-list] exceptions and ECMA issues

Nick Drochak ndrochak@gol.com
Mon, 27 Aug 2001 18:19:42 +0900


Lupus,

In your example there are no nested try-catch blocks, whereas in Carl's
example there is.  What you are looking at in the spec must be talking about
*nested* try-catch blocks, no?

So, in his inner try block, finally handler A must be executed before
control is transferred to the next *outer* catch handler B. In your example,
control is transferred at the point of the throw to catch handler B, and
*then* finally handler C is executed.

Anyway, that's my interpretation.  Or, maybe the difference between your
example and Carl's doesn't clearly show the problem you are having with
this.

HTH,
Nick D.

| -----Original Message-----
| From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com]On
| Behalf Of Paolo Molaro
| Sent: Monday, August 27, 2001 5:45 PM
| To: Mono-List
| Subject: Re: [Mono-list] exceptions and ECMA issues
|
|
| On 08/23/01 Carl R. Witty wrote:
| > > 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 think you're misreading the specification here.
| >
| > Let me give an example.  (Warning: I don't know C#; this is almost
| > certainly not the correct C# exception handling syntax.)
| >
| >   try {
| >     ...
| >     try {
| >       throw ...;
| >     } finally {
| >       // finally handler A
| >     }
| >   } catch {
| >     // catch handler B
| >   } finally {
| >     // finally handler C
| >   }
| >
| > My reading of the paragraph you quoted above is that you must execute
| > "finally handler A" before executing "catch handler B".  The other
| > paragraph you quoted (that I cut from my reply) says you must execute
| > "catch handler B" before "finally handler C".
|
| That is the problem. Partition I is quite clear that the finally handler
| needs to be execute before the catch handler is executed.
| What if the code was simply:
|
| >   try {
| >     ...
| >     throw ...;
| >   } catch {
| >     // catch handler B
| >   } finally {
| >     // finally handler C
| >   }
|
| In this case you'd need to run finally handler C before catch
| handler B and
| that would be backwards.
|
| lupus
|
| --
| -----------------------------------------------------------------
| lupus@debian.org                                     debian/rules
| lupus@ximian.com                             Monkeys do it better
|
| _______________________________________________
| Mono-list maillist  -  Mono-list@ximian.com
| http://lists.ximian.com/mailman/listinfo/mono-list
|
|