Logging Is Not Handling

There is often a great deal of confusion between handling an exception and logging an exception. These are two different things. Handling an exception typically takes one of two forms: either (1) you perform some compensatory action, (e.g. a file is missing, try another place,) or (2) you explicitly choose to carry on without the underlying activity that caused the exception (i.e. you ignore it and go about your business as best you can.); or (3) you notify the user to remedy a situation, especially if it is beyond the ability of the software to remedy (a printer which is out of paper, for instance); or (4) the program fails in a controlled fashion.

Logging is an ancillary activity (and a darn good one) -- but logging is not handling an exception.

(Factored From ThrowDontCatch)

A definition of handling would help, I think. Here's my spin. Handling an error means that the error is no longer of concern for anyone or anything. The process of determining a response to the error ceases once it is handled as it is no longer a problem. Rather, it is a solved problem. Ignoring the problem works on occasion, mind you, but not always. For instance, if the machine is out of memory, handling the out of memory exception properly would require freeing memory. Ignoring it would only deal with the local situation, but you will encounter it again and again until the actual problem is solved. Logging the problem may be necessary if money is being lost, for instance, but that is actually a separate problem (lost money) that occurs as a side effect or a cascade of problems. However, notifying the user that the system is out of memory as Windows does only results in the user rebooting the system. That may solve the problem in a way, but it's not the system that is handling the error, it is the human operator. The system merely lets the error continue to expand scope (up to the human), and the larger the scope, the more expensive the solution. (cf. LimitScope, LimitDamage for sociological takes on the same processes) -- SunirShah

For an opposing view, see LoggingIsHandling.

Occasionally software is used well beyond the contract that created it or even the company that created it. Putting error messages or log entries that say things like "call Dave Johnson" or "contact Gymbal Tech Support" or "please refer to your customer representative" will some day be worse than useless.

I have spent many fun-filled hours, even days, chasing the actual causes of "call Dave Johnson" errors in software packages that no longer have any prayer of tech support from the software's originators.

If you absolutely can't handle the error, then at least provide as much diagnostic information as possible so that the unlucky support person that gets the call two years after "Dave Johnson" has left will have some hope of sorting it out.

-- GarryHamilton

The common solution to Dave not working here anymore is to put severity level and category information in the log messages. The logging system has a database of actions to take (send email, page or call someone, etc.) and the parties that should be notified. Dave is never mentioned in the message. When Dave leaves his replacement assumes his role in the notification database.

... which is okay until the "Dave Johnson" company itself dies or is purchased or in some other way no longer can or will support the software. It's popular to take the "if I'm dead why do I care what the error is?" stance, and that won't always lead to 1999 + 1 = 1900, but it can lead to a business whose day-to-day work is clobbered by an error that might have a simple solution, but you'll never know, 'cuz all you see is "call Gymbal Tech Support".

Whoever runs the software maintains the contact list. I'm not advocating overlooking simple solutions. I'm explaining systems avoid embedding contact information inside code.

So, handle the error, or if that's not possible, present as much information as possible. Unless, of course, you work for Arrogant Software Inc. and you really don't give a damn what happens after you've dissolved the company and started Dewey Cheatum Software.
-- gh

What does this have to do with the discussion?

That's a fair question. Given that I didn't couch my rant in terms of "logging" errors, but rather "reporting" them.

The point is that if you must log it (or report it) because the condition is, by definition, beyond the scope/ability of the program to deal and recover, then ''include anything that will aid analysis'' i.e. as much diagnostic data as you can.

Handling is always preferred. Logging really isn't handling unless it's "your machine is on fire and I can't fix that" or the like.

Handle. When you can't, then log, knowing that this won't fix the problem. When you log, say as much relevant stuff as you can, since somebody will want to have a prayer of fixing what the program can't. -- gh

[ ... later ...] On further reading of SunirShah above, I find I pretty much concur with his assessment: handling the condition means that the continued operation of the program is not at risk nor is it a risk in itself.

My focus on "what to do when you don't handle" is tangental.

My best example of really handling a condition is in TreePad. The program will actually fully recover from a GPF. It pops up a dialog saying that something horrible has happened, and then it sweeps up all the broken glass, mops up the spills, and returns you to unimpaired normal operation. Very clean. -- gh

see LoggingIsHandling, LoggingDiscussion

CategoryLogging