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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
