Question

I have an app that runs a long batch process where many exceptions could potentially be thrown. If a non-critical exception is thrown during one item in the batch, I want to simply log it and continue, so we can fix the problem later while letting the other batch items continue.

Some exceptions, such as OutOfMemoryException, are devastating to the app as a whole, and these I would like to rethrow so that they bubble up to global exception handler which will log the error and stop the app.

So my question is, is there a reasonbly short list of critical exceptions that I can rethrow in my lower exception handler while suppressing (after logging) everything else?

Thanks!

Edit: To elaborate a little, here is the basic structure of my program

foreach(var item in longItemList)
{
   try
   {
      bigDynamicDispatchMethod(item);
   }
   catch(Exception ex)
   {
      logException(ex);
   }
}

There are potentially a huge number of exceptions that could be thrown because this loop is pretty much at the top level of my app. 99% of the code in my project is behind the dispatch method. I do reasonable exception handling at lower levels, but bugs still work their way in and I don’t want to stop other unrelated processes in the batch after an exception is thrown.

Trying to find which exceptions could be thrown everywhere else in my app seems like a daunting task, and it seemed to be that it would be simpler to get a blacklist of critical exceptions.

Is there a better way to structure my app to deal with this? I am open to suggestions.

Answer 1

You don’t need a list of ‘bad’ exceptions, you should treat everything as bad by default. Only catch what you can handle and recover from. CLR can notify you of unhandled exceptions so that you can log them appropriately. Swallowing everything but a black listed exceptions is not a proper way to fix your bugs. That would just mask them. Read this and this.

Do not exclude any special exceptions when catching for the purpose
of transferring exceptions.

Instead of creating lists of special exceptions in your catch clauses,
you should catch only those exceptions that you can legitimately
handle. Exceptions that you cannot handle should not be treated as
special cases in non-specific exception handlers. The
following code example demonstrates incorrectly testing for special
exceptions for the purposes of re-throwing them.

public class BadExceptionHandlingExample2 {
    public void DoWork() {
        // Do some work that might throw exceptions.
    }
    public void MethodWithBadHandler() {
        try {
            DoWork();
        } catch (Exception e) {
            if (e is StackOverflowException ||
                e is OutOfMemoryException)
                throw;
            // Handle the exception and
            // continue executing.
        }
    }
}

Few other rules:

Avoid handling errors by catching non-specific exceptions, such as
System.Exception, System.SystemException, and so on, in application
code. There are cases when handling errors in applications is
acceptable, but such cases are rare.

An application should not handle exceptions that can result in an
unexpected or exploitable state. If you cannot predict all possible
causes of an exception and ensure that malicious code cannot exploit
the resulting application state, you should allow the application to
terminate instead of handling the exception.

Consider catching specific exceptions when you understand why it
will be thrown in a given context.

You should catch only those exceptions that you can recover from. For
example, a FileNotFoundException that results from an attempt to open
a non-existent file can be handled by an application because it can
communicate the problem to the user and allow the user to specify a
different file name or create the file. A request to open a file that
generates an ExecutionEngineException should not be handled because
the underlying cause of the exception cannot be known with any degree
of certainty, and the application cannot ensure that it is safe to
continue executing.

Eric Lippert classifies all exceptions into 4 groups: Fatal, ‘Boneheaded’, Vexing, Exogenous. Following is my interpretation of Eric’s advice:

  Exc. type | What to do                          | Example
------------|-------------------------------------|-------------------
Fatal       | nothing, let CLR handle it          | OutOfMemoryException
------------|-------------------------------------|-------------------
Boneheaded  | fix the bug that caused exception   | ArgumentNullException
------------|-------------------------------------|-------------------
Vexing      | fix the bug that caused exception   | FormatException from 
            | (by catching exception  because     | Guid constructor
            | the framework provides no other way | (fixed in .NET 4.0 
            | way of handling). Open MS Connect   | by Guid.TryParse)
            | issue.                              | 
------------|-------------------------------------|-------------------
Exogenous   | handle exception programmatically   | FileNotFoundException 

This is roughly equivalent to Microsoft’s categorization: Usage, Program error and System failure.
You can also use static analysis tools like FxCop to enforce some of these rules.