Log every time an exception is handled

Question

I have noticed a discrepancy in views on logging and wanted to provide a poll on this issue to the SO community. C.f. a similar question but not as a poll.

Poll: Should exception handlers ALWAYS write to the log any time an exception is caught and handled?

Note: This is not a question about how to handle the exception, or on how to re-throw the exception.

Answer 1

There are some very specific cases where you can just ignore an exception but in most cases you should log it. If you ever want to find out at a later point in time what happened inside your application, log the exceptions it throws.

Answer 2

There are some situations where an exception is expected, and does not need to generate a log line (for example, dealing with certain types of hardware interrupts). However, unexpected exceptions which are caught should always be logged.

Answer 3

This is why an exception handling and logging framework is so important. It's very helpful to be able to modify in configuration what type of exceptions are logged and what particular logging level the application is running under.

I think the architectural mistake is to assume that the same exception handling and logging policy is to be in effect at all times. Policies will and should change and your architecture should support the ability to make those changes with minimal code and deployment impact. There are many good frameworks out there that provide this type of functionality.

Answer 4

In Python a blanket policy of logging every exception is unrealistic.

The StopIteration exception is used widely. It's an essential ingredient in the for statement, and doesn't represent an error.

Similarly, it's acceptable practice in Python to use exceptions instead of if-statements.

For example

if key in mapping:
    process(mapping[key])
else:
    somethingelse()

is the same as

try:
    process(mapping[key])
except KeyError, e:
    somethingelse()

The second form is widely used and may not represent something erroneous. It depends on the indent of the designer whether or not this exception is an error -- and should be logged -- or is simply an exception that is being ignored.

Answer 5

Yes, even any 'expected' exceptions should be logged (I'm thinking of, for example, exceptions thrown when a network connection dies, which is a fairly ordinary event).

However, although the logging is built-in to the software, the amount of logging that's actually enabled at run-time should be configurable at run-time: sometimes you only want to log really severe problems (e.g. software assertion failures), sometimes ordinary events, and sometimes debug-level events ... stereotypically, "error", "warning", "info", and "debug" levels of warning.

Answer 6

Always? No. Unhandled or serious? Yes.

For example if you write a WCF custom username and password authenticator someone at MS made the stupid decision that the return type from the authenticate method is null. You indicate that someone got their password wrong by, err, throwing an exception. To me this isn't an exceptional event. Now this is a contrived example as you'd probably want to log password failures somewhere, but not as the result of an exception!

Answer 7

Here some points, Jeffrey Richter states:

An exception is not a bad thing unless it is unhandled. Logging every exception thrown is like logging every method that returns false there is no value to this.

Sometimes, the code higher up the call stack catches the exception, logs it, and then rethrows. And now, you have the same entry repeated multiple times in the log, hurting your performance, and providing multiple entries in the log for you to review. And, if the exception is handled higher up, then you are now reviewing something that was handled appropriately and you are just wasting your time.

When an unhandled exception occurs is when you know you have a bug. At this time, you can connect a debugger (locally or remotely) to solve the problem. Or get a minidump of the process and then open the DMP file in a debugger to see what went wrong. Visual Studio 2010 lets you now do this for .NET processes.

My CLR via C# book has a big chapter on this and I have rewritten the chapter substantially in the new edition (due out in February 2010) that goes into this more. The .NET Design Guidelines book also goes into the proper use of Exceptions. Of course, I was involved in the production of both of these and so if you are doubting what I say, then you should look for other sources of information.