Exceptions to Never Catch

Question

I know that there are some exception types that cannot be caught in catch blocks, like StackOverflowException in .NET 2.0. I would like to know which other exceptions are inadvisable to catch, or are associated with bad practices.

The way I would like to use this list of exception types is to check it every time I am using Exception in a catch block:

private static readonly Type[] _exceptionsToNotCatch = new Type[] { typeof(StackOverflowException) };

// This should never throw, but should not swallow exceptions that should never be handled.
public void TryPerformOperation()
{
    try
    {
        this.SomeMethodThatMightThrow();
    }
    catch (Exception ex)
    {
        if (_exceptionsToNotCatch.Contains(ex.GetType()))
            throw;
    }
}

EDIT

I don't think I provided a very good example. That's one of the problems with trying to make an example trivial when trying to communicate one's meaning.

I never throw Exception myself, and I always catch specific exceptions, only catching Exception as follows:

try
{
    this.SomeMethodThatMightThrow();
}
catch (SomeException ex)
{
    // This is safe to ignore.
}
catch (Exception ex)
{
    // Could be some kind of system or framework exception, so don't handle.
    throw;
}

My question was meant as more of an academic one. What exceptions are only thrown by the system and should never be caught? I am worried about situations more like this:

try
{
    this.SomeMethodThatMightThrow();
}
catch (OutOfMemoryException ex)
{
    // I would be crazy to handle this!
    // What other exceptions should never be handled?
}
catch (Exception ex)
{
    // Could be some kind of system or framework exception, so don't handle.
    throw;
}

This question was really inspired by the following: System.Data.EntityUtil.IsCatchableExceptionType(Exception) in System.Data.Entity, Version=3.5.0.0

Answer 1

I would like to know which other exceptions are inadvisable to catch, or are associated with bad practices.

Here is the list of all exceptions you shouldn't catch:

1. Any exception you don't know what to do with

Here's the best practice for exception handling:

If you don't know what to do with an exception, don't catch it.

This may sound snarky, but they're both correct, and that's all you need to know.

Answer 2

It's generally not a good idea to do that.

You should catch the most specific exception(s) possible and only carry on execution of your program when it is safe to do so. E.g. if you're opening a file, it's perfectly reasonable to catch exceptions relating to file access / permission errors, but probably not much else. You certainly wouldn't want to catch an OutOfMemoryException and then blindly carry on. They're very different errors!

If you apply a blanket rule of what to catch, there's no guarantee that your program will be able to continue execution safely because you're not responding to specific situations, just applying a one size does not fit all solution.

Answer 3

Using Exception in the catch block would catch all exceptions that are catchable. I would say you should specify only exceptions that needs to be caught and let the ones you don't want to catch spill out. E.g.

try
{

}
catch(SqlException sqlex)  //specific to database calls
{
   //do something with ex
}
catch(FormatException fex) //specific to invalid conversion to date, int, etc
{
   //do something with ex
}
catch(Exception ex)
{
    //I didn't know this exception would be thrown
    //log it for me or Rethrow it
}

Any other exception not in that list will not be caught

Answer 4

Okay so we've established it ain't a good idea. And we've established that programmers on SO prefer to opine from their high-horses rather than hand you a knife to stab yourself with, so for those with suicidal tendencies, let's start with these:

(Redacted my list and DRYing-up SO to point to Hans' list)

https://stackoverflow.com/a/5508733/17034