[Mono-bugs] [Bug 68552][Nor] Changed - Abort exception not properly rethrown in some cases

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by kornelpal at hotmail.com.

http://bugzilla.ximian.com/show_bug.cgi?id=68552

--- shadow/68552	2005-07-06 16:19:08.000000000 -0400
+++ shadow/68552.tmp.28751	2005-07-06 17:33:57.000000000 -0400
@@ -141,6 +141,83 @@
      }
      Console.WriteLine ("Should not print this");
 }
 
 The MS runtime will print the message.
 
+
+------- Additional Comments From kornelpal at hotmail.com  2005-07-06 17:33 -------
+Zoltan, your last test does the same on MS runtime and Mono and it 
+is the expected behaviour. But "Should not print this" should 
+be "Has to print this".
+
+Lluis, your last test works as expected on MS runtime but should be 
+fixed in Mono.
+
+Documentation:
+http://msdn.microsoft.com/library/en-
+us/cpref/html/frlrfsystemthreadingthreadabortexceptionclasstopic.asp
+
+ThreadAbortException is a special exception that can be caught, but 
+it will automatically be raised again at the end of the catch block. 
+When this exception is raised, the runtime executes all the finally 
+blocks before killing the thread.
+
+It is not mentioned but of course all the appropriate catch blocks 
+are executed because the exception is being rethrown until 
+ResetAbort is called or unwinding reach the beginning of the stack.
+
+An important thing is however missing from the documentation:
+ThreadAbortException is a special exception that can be caught, but 
+it will automatically be raised again at the end of the catch block 
+[that catched ThreadAbortException].
+
+So the behaviour does not depend on whether you use functions, inner 
+exceptions or inner catch blocks or how do you catch 
+ThreadAbortException.
+
+The only important thing is that ThreadAbortException will be 
+rethrown when the catch block that catched ThreadAbortException is 
+leaved unless ResetAbort was called inside the catch block. As 
+ThreadAbortException is rethrown it can be catched by uplevel catch 
+blocks and then it will be rethrown.
+
+And this is reasonable because you may want to do more complex work 
+when handling ThreadAbortException. For example you may want to log 
+it but suppress I/O exceptions. Rethrowing ThreadAbortException when 
+leaving catch blocks that don't catched ThreadAbortException could 
+cause problems. And of course there is no need to rethrow it before 
+leaving the catch block that catched it.
+
+But if you embed a catch block inside a catch block that catched 
+ThreadAbortException then ThreadAbortException will be rethrown only 
+when the catch block that catched ThreadAbortException is leaved and 
+not when any catch block that catched non-ThreadAbortExceptions are 
+leaved.
+
+And of course it does not matter how the ThreadAbortException was 
+catched: catch, catch (Exception), catch (ThreadAbortException) or 
+anything else that can catch ThreadAbortException.
+
+Another important thing is that you can throw a different exception 
+before the catch block that catched ThreadAbortException in this 
+case ThreadAbortException will not be rethrown until an uplevel 
+catch block that catched the new exception is leaved normally. In 
+addition exceptions can be thrown by finally blocks as well. In this 
+case the same applies as form catch blocks: ThreadAbortException 
+will be rethrown when a catch block that catched the new exception 
+is leaved.
+
+The above situation is handled by MS runtime and Mono correclty but 
+it is important to mention this case. This solution is reasonable 
+becasue ThreadAbortException is needed to abort the thread using an 
+exception and it's the same from this point of view to have a 
+ThreadAbortException or any other exception on the stack. 
+ThreadAbortException has to be rethrown however when the other 
+exception is catched to can continue thread abortion.
+
+Note that I am talking about ThreadAbortException but in fact this 
+behaviour is based on thread aborting and not the exception itself. 
+If I "throw (ThreadAbortException)Activator.CreateInstance(typeof
+(ThreadAbortException), true);" it behaves the same as a regular 
+exception on MS runtime and Mono as well. And this is the expected 
+behaviour.