Why CLR re-throws ThreadAbortException?

Question

I got the following code from book "Concurrent Programming on Windows" :

void Main()
{
    try
    {
        try
        {
            Console.WriteLine("Inside Main Method");
            Thread.CurrentThread.Abort();
        }
        catch(ThreadAbortException)
        {
            Console.WriteLine("Inside First Catch");
            // Trying to swallow but CLR throws it again....
        }
    }
    catch(ThreadAbortException)
    {
        Console.WriteLine("Inside Second Catch");
        //Thread.ResetAbort();
    }
}

I am interested in knowing as why CLR re-throws the ThreadAbortException ? And it keeps doing it until I call "Thread.ResetAbort()". Secondly, is there any other system defined exception, which gets special treatment from CLR ?

Giese

Also note, that the code, calling Thread.ResetAbort() needs special permission to be able to do so. So, if you are hosting CLR or creating an AppDomain you might use this feature to make aborting threads more deterministic. – Matriarch

Answer 1

I am interested in knowing as why CLR re-throws the ThreadAbortException?

Because the thread is being aborted. People handle all exceptions all the time, even though doing so is dangerous. It would be bizarre if an error logging routine, say, kept a thread that was supposed to be destroyed alive forever, no?

is there any other system defined exception, which gets special treatment from CLR?

Yes, there are several. Out of stack and out of memory exceptions, for example, also have special behaviours.

Ashia

Thanks for the answer. Just wanted to ask, now given that I am aware of this behavior, is it recommended practice to encapsulate thread based code inside "ThreadAbortException" try-catch block? As the exception is anyways going to be re-thrown, the behavior might surprise someone who is not aware of the way this exception behaves. – Giese

@PawanMishra: Two good rules come to mind. The first is "never abort a thread". Terminate a thread normally; if you can't, kill the entire process. Aborting a thread is insanely dangerous. Second, "never handle an exception that you can't do something about." There is never anything good to do when a thread is being aborted. Since you're never going to abort a thread, and never going to handle the exception if you do, writing the catch block is a bit pointless, right? – Ashia

Re-asking the OPs second question: Are there any "system defined exceptions [that] get special treatment from the CLR"? There are thread/process states that cause things to happen, but I don't see the exceptions themselves alone being special cased, as can be seen here. Obviously I had to jump a hoop or two to allow my code to (re)throw a ThreadAbortException myself, and there may be other exceptions that do do funny things when thrown, but these don't seem to. (True stack overflow and aborted thread states obviously do have special treatment.) – Flowerdeluce

Answer 2

It's a special exception, http://msdn.microsoft.com/en-us/library/system.threading.threadabortexception.aspx, see remarks. From my understanding the reason this happens is that .Net is giving you the ability to do any clean up work before the thread closes.

See this for a bit about the plumbing: http://ondotnet.com/pub/a/dotnet/2003/02/18/threadabort.html

Bunker