.NET Trivia

Here’s a fun piece of .NET trivia involving thread aborts and exception handling.  What does the following code do?  And why does it do it?


using System;

using System.Threading;


class TATest


        public static void Main(string []args)









                        if((Thread.CurrentThread.ThreadState & ThreadState.AbortRequested)!=0)






                Console.WriteLine(“Bye bye!“);  




(In writing this I’ve discovered my fingers really prefer to type byte over bye…  that t just seems so natural to come next).b

Comments (5)

  1. David Levine says:

    The code above will not reset the abort.

    Aborting a thread in the manner done here is equivalent to throwing a synchronous abort into the thread since its aborting itself. The runtime raises a ThreadAbortException on the thread and uses the Structured Exception Handling mechanism for dealing with the exception.

    On the 1st pass of the SEH the runtime searches the call stack for a catch block to handle the exception. It will not find one. It then calls any registered unhandled exception handlers, which in this case do not exist (none were registered or not shown in this snippet). This completes the first pass of the SEH.

    On the 2nd pass it goes back and calls all finally blocks. The finally block in the code is called. Since an abort was requested the test succeeds and it executes the code that calls ResetAbort. This call does nothing useful because that call must be made in the context of the catch handler on the 1st pass of the SEH mechanism. ResetAbort cancels an abort exception, but for this to be meaningful it must be done in a catch block.

    The line of code that writes Bye-bye will never execute because as soon as the finally block has executed the runtime will continue searching back up the call stack for the next finally block to run. When it reaches the end of the callstack it will terminate the thread. If this was the main thread then the applcation will terminate.

  2. David Levine says:

    Minor correction. The catch handlers execute on the 2nd pass, not the 1st pass. The 1st pass searches for the handler, and the 2nd pass executes downstream finally blocks and then the catch handler. The call to ResetAbort must be done in the catch handler, but this executes after the 2nd pass has completed.

  3. David’s explanation hits the nail right on the head. It’s very unintuitive because Thread.ResetAbort gets called, but the thread still goes away… I don’t think anyone would ever do this – at least not on purpose – but if they did they’d get quite the surprise.