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 ?

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. — Konstantin, Nov 23 '11 at 07:55

score 15 · Accepted Answer · answered Nov 23 '11 at 06:41

15

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.

answered Nov 23 '11 at 06:41

Eric Lippert

647,829
179
1,238
2,067

1

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. – Pawan Mishra Nov 23 '11 at 07:12
4

@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? – Eric Lippert Nov 24 '11 at 15:16
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](http://share.linqpad.net/hs2pkf.linq). 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.) – Mark Hurd Feb 13 '14 at 05:21

score 3 · Answer 2 · answered Nov 23 '11 at 06:09

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

Why CLR re-throws ThreadAbortException?

2 Answers2