17

A lot of times, it is mentioned to only catch exceptions which I can handle (throw, wrap and/or log, or perform some other actions).

Which exceptions cannot be handled? Is this the same meaning as should not be caught? I know that exceptions which may represent an object reference being null should not be caught, because they are programming errors and not user-provoked. Is there any other example? Another one is ExecutionEngineException.

Also, is the course of action in a catch block always just between rethrow, wrap/rethrow and log? Is there ever a case where some other action needs to be performed in a catch block?

Thanks

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
GurdeepS
  • 65,107
  • 109
  • 251
  • 387
  • 4
    I don't really understand this question. You *know* which exceptions you can handle. It's the ones you've specifically written *code* in the exception handler to handle. It's the ones that you can *fix*. **If you're not sure, you can't handle them, so you shouldn't catch them.** – Cody Gray - on strike Apr 01 '11 at 00:15
  • Responses to this question may also be helpful: http://stackoverflow.com/q/7152354/625332 – Dmitry Aug 22 '11 at 21:10

3 Answers3

16

The usual advice applies, only catch what you can handle. There's a utility function named IsCriticalException inside the framework that's pretty commonly used by parts of the framework code to decide whether or not to swallow an exception. Might as well go by that. It considers the following critical:

  • NullReferenceException
  • StackOverflowException (uncatchable)
  • OutOfMemoryException
  • ThreadAbortException
  • ExecutionEngineException (uncatchable in 4.0)
  • IndexOutOfRangeException
  • AccessViolationException

It is a good list.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • 1
    Most properly written applications would not need to know this list because they will treat all unhandled application the same: they will just let CLR terminate the process. They will not swallow everything but a list_of_exceptions_that_is_considered_to_be_critical_by_Microsoft.VisualStudio.Shell.10.0. It is interesting to know that such method exists thought. – Dmitry Aug 22 '11 at 20:44
  • [Is this the property you're talking about?](http://msdn.microsoft.com/en-us/library/vstudio/microsoft.visualstudio.errorhandler.iscriticalexception.aspx) I don't see any other similar handlers. –  Sep 23 '13 at 02:59
  • 1
    System.ClientUtils.IsCriticalException, it is an internal method. – Hans Passant Sep 23 '13 at 06:07
15

I would use Eric Lippert's advice and not catch "Fatal" exceptions:

https://ericlippert.com/2008/09/10/vexing-exceptions

Mat Hobbs
  • 5
  • 3
anon
  • 4,578
  • 3
  • 35
  • 54
  • here is the exception hierarchy for C# http://msdn.microsoft.com/en-us/library/z4c5tckx(v=vs.80).aspx – m4tt1mus Apr 01 '11 at 00:10
  • 1
    Eric also suggests not catching "Boneheaded" exceptions, since doing so is hiding bugs in your code. – Brian Apr 01 '11 at 16:48
  • The correct link is [Exception Hierarchy](http://msdn.microsoft.com/en-us/library/z4c5tckx.aspx) – John Saunders Mar 02 '12 at 01:58
  • The link is good, Eric's blog is always worthwhile to read. But it doesn't answer the question which exceptions cannot be catched. The closest answer for this was given by Hans Passant. – Matt Nov 05 '21 at 08:26
0

The course of action in a catch block may not always be rethrow, wrap/retrow and log. I've seen where a db exception, like a deadlock, causes an exception to be thrown and then the catch logic attempts to perform the database action again in hope that the locked resource is no longer locked.

David Hoerster
  • 28,421
  • 8
  • 67
  • 102