ThreadAbortException

Solution 1:

Actually yes, a ThreadAbortException is special. Even if you handle it, it will be automatically re-thrown by the CLR at the end of the try/catch/finally. (As noted in the comments, it can be suppressed with ResetAbort but by that point the code smells like rotten fish.)

Not to mention even though there is no obvious executable code outside of your try/catch/finally, every iteration of the loop winds up outside of the scope for a small duration so the abort could occur outside of your try block.

Unless you are actually doing something in the catch block, I would just make a try/finally and don't worry about ThreadAbortException. There are much better ways of aborting a thread without using Thread.Abort which not only chaotically interrupts your code at an unpredictable point, it's also not guaranteed to work because if your thread is currently calling out to some unmanaged code, the thread will not abort until control returns to managed code.

It's much better to use some type of synchronization primitive such as a ManualResetEvent to act as a flag telling your thread when to exit. You could even use a boolean field for this purpose which is what the BackgroundWorker does.

Solution 2:

Yes. I suspect that you're asking because thread interruptions only occur when a thread could otherwise block (or if it's already blocked) - e.g. for IO.

There's no such guarantee for abort. It can happen at any time, basically, although there are delay-abort regions such as constrained execution regions and catch/finally blocks, where the abort request is just remembered, and the thread aborted when it exits the region.

Synchronous thread aborts (i.e. aborting your own thread) is reasonably safe, but asynchronous aborts (aborting a different thread) are almost always a bad idea. Read "Concurrent Programming on Windows" by Joe Duffy for further information.

EDIT: As noted by Eric below, aborting another thread isn't guaranteed to actually have any effect either. Just to quote the comment:

I would have said that the thread is aborted if it exits the region, emphasizing that Thread.Abort is completely unreliable. A thread which being aborted because it is stuck in an infinite loop will not abort if the loop is in such a region. This is yet another reason why Thread.Abort is a bad idea; if you can't rely on the desired effect actually happening then why would you call the method?

Solution 3:

Actually, ThreadAbortException is special in case it's thrown by CLR or Thread.Abort method. Compare output:

• Slightly modified example (added Console.WriteLine) from Joe Duffy's "Concurrent Programming on Windows". It throws the exception by Thread.CurrentThread.Abort:

  
  try
  {
      try
      {
          Thread.CurrentThread.Abort();
      }
      catch (ThreadAbortException)
      {
          Console.WriteLine("First");
          //Try to swallow it.
      } //CLR automatically reraises the exception here .
  }
  catch (ThreadAbortException)
  {
      Console.WriteLine("Second");
      Thread.ResetAbort();
      //Try to swallow it again .
  } //The in - flight abort was reset , so it is not reraised again .
  
  
  

  Output:

  First
  Second
  

• Modify previous example to use different approach of ThreadAbortException instance creation:

  
  try
  {
      try
      {
          // get non-public constructor
          var cstor = typeof(ThreadAbortException)
              .GetConstructor(BindingFlags.Instance | BindingFlags.NonPublic, null, Type.EmptyTypes, null);
          // create ThreadAbortException instance
          ThreadAbortException ex = cstor.Invoke(null) as ThreadAbortException;
  
          // throw..
          throw ex;
      }
      catch (ThreadAbortException)
      {
          Console.WriteLine("First");
      } 
  }
  catch (ThreadAbortException)
  {
      Console.WriteLine("Second");
      Thread.ResetAbort();
  } 
  

  Output:

  First
  

It seems like Thread's methods call native code internally which makes raised exception specific.