0

I'm working in a legacy project that has this exception handling code in many methods. 

catch(ThreadAbortException e)
{
  ...
}

I don't see anywhere in the project Thread.Abort() or Thread.Interrupt() calls. Is it safe to delete all these ThreadAbortException handling or it is some other way that can be raised.

albert
  • 1,493
  • 1
  • 15
  • 33

3 Answers3

1

Official docs: "The exception that is thrown when a call is made to the Abort method." If you are completely sure there are no calls to Thread.Abort then you might as well erase those catch blocks.

EDIT: Be mindful that your code may be running in the context of an external app that may call Thread.Abort on your threads.

Not that it matters anyway as a ThreadAbortException can't really be handled as the CLR itself will rethrow it to actually kill the thread ASAP.

"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.)" - Read this question for more details: ThreadAbortException

Community
  • 1
  • 1
Machinarius
  • 3,637
  • 3
  • 30
  • 53
  • @downvoter Care to explain why you downvoted this answer? – Machinarius Jun 18 '16 at 15:55
  • 3
    Not my downvote, but: you're saying that based on the documentation, the only way for `ThreadAbortException` to be thrown is when `Thread.Abort` is called. Firstly, that's wrong: there's nothing preventing you from throwing a `ThreadAbortException` manually with a `throw` statement (even though it cannot be instantiated directly, it can be caught and saved). Secondly, that's misleading: although the OP's code may not contain any direct calls to `Thread.Abort`, the OP may be making use of external code that does call `Thread.Abort`, a notable example being Microsoft's IIS web server. –  Jun 18 '16 at 15:58
  • 1
    Of course you can manually throw it but doing it that way won't mean anything special over it being a thrown exception IIRC, unlike calling Thread.Abort that will cause the CLR to throw as many TAE instances as needed to kill the thread ASAP. Your IIS remark is very valid though. – Machinarius Jun 18 '16 at 16:03
  • You're right that manually thrown TAEs are not special. They would still hit the OP's `catch` block though. But I must admit I don't consider the probability of that happening very high. –  Jun 18 '16 at 16:09
1

Well if answering specifically your question I would say that it would be better not to delete these exception handlers as it’s most likely that they were added by some developer trying to solve a problem. And I think there was a reason to add those handlers so if you just remove this code it can lead to appearing of some bugs again in the future.

Regarding the ThreadAbordException: I know for sure that it can be throwed not only with calling Thread.Abort() method when you are debugging (it might be a bug in VS, I’m not sure) and it forces your program to just crash silently. So depending on what’s inside of those handlers it could be possible that a developer was trying to solve such problem.

Also remember that you could be invoking methods of third-party libraries, web-services etc. in a separate thread, too. I’m not sure if they can throw such an exception but that’s a possible case to consider.

Ivan Yurchenko
  • 3,762
  • 1
  • 21
  • 35
1

Is the project running on a main thread and spinning up background worker threads? If the main thread exits while background threads are running, a ThreadAbortedException can occur on the background threads.

The catch statement could specifically handle this scenario, where no error actually occurred on the background thread, in a different manner than any other exception.

mfreedm52
  • 161
  • 10