[Mono-list] exception semantics

[Morten Sylvest Olsen]

On Tue, 29 Jan 2002, Jeroen Frijters wrote:

> This is the correct behaviour, since you explicitly return from the
> catch block.

Hmm, can that really be correct?. I wasn't aware of this semantic change
from the Java behavior! I haven't got a windows system handy to test on
right now.

It doesn't look right when I look at the CIL either:

      .try { // 0
	  .try { // 1
	    IL_0000: ldstr "In try"
	    IL_0005: call void System.Console::WriteLine(string)
	    IL_000a: ldc.i4.1
	    IL_000b: stloc.1
	    IL_000c: leave.s IL_0036
		     ^^^^^^^^^^^^^^^^
Here I leave both the enclosing try-blocks.

	  } // end .try 0
	    ^^^^^^^^^^^^^

That looks like a bug in monodis. This must be the end of try-block 1? Or
else the nesting requirements of I.11.4.2.7 are violated.


	  catch [mscorlib]System.Exception { // 0
	    IL_000e: stloc.0
	    IL_000f: ldstr "In catch"
	    IL_0014: call void System.Console::WriteLine(string)
	    IL_0019: leave.s IL_001b

	  } // end handler 0
	  IL_001b: leave.s IL_0028

	} // end .try 1
	finally  { // 1
	  IL_001d: ldstr "In finally"
	  IL_0022: call void System.Console::WriteLine(string)
	  IL_0027: endfinally
	} // end handler 1
	IL_0028: ldstr "After finally"
	IL_002d: call void System.Console::WriteLine(string)
	IL_0032: ldc.i4.0
	IL_0033: stloc.1
	IL_0034: br.s IL_0036

	IL_0036: ldloc.1
	IL_0037: ret

So why isn't the finally handler executed? I must be missing something
important.

- Morten

Preudhomme's Law of Window Cleaning:
	It's on the other side.
----------------------------------------------------------
email: morten@bergsoe.k-net.dk,c958496@student.dtu.dk
addresse: Bergsøe Kollegiet v. 1105 2850 Nærum
----------------------------------------------------------