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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…