Which types of exception not to catch?

Question

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

Noakes

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. – Micron

Responses to this question may also be helpful: https://mcmap.net/q/716085/-which-exceptions-shouldn-39-t-i-catch/625332 – Intimidate

Answer 1

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.

Crean

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. – Intimidate

Is this the property you're talking about? I don't see any other similar handlers. – Paripinnate

System.ClientUtils.IsCriticalException, it is an internal method. – Crean

Answer 2

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

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

Marilynnmarimba

here is the exception hierarchy for C# msdn.microsoft.com/en-us/library/z4c5tckx(v=vs.80).aspx – Prevaricator

Eric also suggests not catching "Boneheaded" exceptions, since doing so is hiding bugs in your code. – Mira

The correct link is Exception Hierarchy – Cele

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. – Superscribe

Answer 3

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.

Vapory