Logging Is Handling
Logging Is HandlingLogging an exception is one way to handle it. Whether that's the appropriate way to handle it depends on the exception and the requirements. Some exceptions can't be handled any other way. Some exceptions would be too costly to handle any other way.
How about some thoughts about what makes the difference for whether logging is or isn't handling?
Logging is handling. It may not be the best way to handle a specific exception, but that's true for any form of exception handling, not just logging.
I think it's clear that logging is not handling since the exception is just "rethrown" up to the human operator. If your view of the system is limited to the software, you may not fully appreciate that I just said, but the error cannot be said to have been handled if it is still gaining new attention from other parts of the entire system. And where this matters for programmers is that one shouldn't put an over-reliance on logging as a method of handling errors since the error should be fixed as close to the source of the problem as possible; otherwise, it is a CodeSmell. That is, an indication of a bug or wart. So while logging is necessary to deal with problems outside the scope of the system, such as money lost or hardware that is failing, it is merely a stop valve for dealing with other types of problems you have yet to find and fix. Why this page was moved from LoggingIsNotHandling is a bit specious to me since we had not come to a synthesis in the discussion; a bit of PrematureAbstraction. -- SunirShah
This page was created to express the opposing view. Synthesis is not the goal. You have expressed your view on LoggingIsNotHandling. I am expressing mine on LoggingIsHandling. Nowhere on this page do I say that programmers should rely on logging when an error could be better resolved in some other way. -- EH
Logging is simply documenting the occurrence of an exception. Handling is doing something about the exception. Exceptions that are too costly or have no way of handling are simply not handled. -- TimRhodes
Yes, they are handled by logging them.
Anything that happens inside a catch block is "exception handling". If all the code does is log the exception, that's how it handles the exception. Logging is the most common form of exception handling in my experience.
No, the catch block is the handler, and a bad one. A good handler would try to fix whatever is wrong. Logging is for diagnostic autopsies (post-modern or in-vivo). They help programmers come to the system later on and determine what the actual source of the problem was so that they can correct it. However, handling an exception really means automating the response to that exception, and that means you need code in the system to do this. A catch block with only logging code does nothing to solve the problem, and thus can only be said to be rethrowing the exception up to the programmer. -- SunirShah
There are situations (and entire domains) where there is no way to fix an exception. If a problem could be fixed it would never have thrown an exception. In these situations, exception means the problem is outside the scope of the system and requires human attention. Transaction processing systems are generally built this way. -- EricHodges
I suppose we could extract a couple points.
In the transaction processing world I worked in, handling was not equated with fixing. Exception handling meant taking the appropriate action in response to an exception, no matter what that action was. In these systems the problems that could be fixed generally were fixed at the point of failure. No exceptions were involved. The presence of an exception indicated that a problem had occurred outside the scope of the system. Logging is one valid way to handle exceptions. It depends on the context. -- EH
This is my argument: For someone like the system owner, I still need to know why transactions that needed to take place didn't, and what we are going to do about it if it's costing us money. To the owner, the exception is still not handled at the point of logging, and although it's no longer the problem of the programmer, you've only just passed it on ("rethrown it") to someone else to "handle." In this way, the exception continues to peel back up the system layers into higher and higher scopes, just like it does through the code, except the system doesn't merely stop abruptly at the system prompt, but extends into the human world as well. Maybe I'm missing how you are using your log file, though. How is it used? -- SunirShah
We used our logging system to notify operators about failures the software couldn't work around. There were teams of them on duty at all times. The logging system would send email to text pagers telling them where the problem occurred and at what time. By viewing the complete log file for that system at that time they could diagnose the problem and take corrective action. -- EricHodges
So in fact you are not handling the exception, but propagating it to people - who are more expensive, which is critical to understand why logging is not handling. Handling the error as close to the source of the problem as possible is the cheapest solution. While the phrase "software couldn't work around" doesn't indicate whether it is really a problem in the internal model of the software or a problem outside the scope of the software, it's important to not believe that you can simply pass the buck with the logging system rather than figure out how to fix the error if you can, since wasting your customers time doesn't seem like a good idea. (Although it does create support contracts, which generate revenue.) -- SunirShah
Some exceptional circumstances occur so rarely or require such complex "fixes" that it makes sense for the system to delegate the exception handling to people. Writing code to intelligently handle an exception has a cost associated with it, and the benefit of handling an exception that rarely or never happens may not be justified. Trying to write code to handle every possible exception (as well as every "impossible" exception) can be GoldPlating. YAGNI applies to exception handling as well as it does to any other kind of code. -- KrisJohnson
I think there is also the danger of handling those complex errors wrongly - the "corrective" action taken in the handler might actually make things worse (especially when you're operating on persistent data; it could be a long time before you find the problem you just created...). I'm not arguing for logging instead of handling, but I think there's a time for both. If something really unusual is happenning, it might be safer to just log what you can, rollback, and quit. At least that way you keep the data safe. (Obviously this depends on the application though. I wouldn't like to wander up to the display of an air traffic control system and see "an exception has occurred in this application..."). -- KevinMcConnell
Much of the above depends on who the log is intended for. Many logfiles are intended only for programmers, logging into such a file is not (in and of itself) handling the error (though the correct "handling" of the error may be to do nothing; arguably the log should say that).
Many other logfiles (such as the database example above) are intended for users (usually, technically sophisticated ones such as system admins or DB admins); if the purpose of logging an error is to allow the human to take corrective action, then logging can be considered a form of handling. Even in simple apps, if the error is "network isn't plugged in", notifying the user of this fact so that he/she can plug the network in is a way to handle the error (and the only way, as the software cannot physically install the network connection itself).
Note that user error messages like "your program is crashed; please notify us" where the user cannot perform any meaningful intervention aren't a form of handling by themselves. However, a controlled crash may be considered error handling, if no other recovery method is possible.
-- ScottJohnson
All true, all good points. But there's a remaining point to this page: logging should not be treated as an excuse to avoid thinking about how better to automatically handle an exception, when possible and appropriate.
Panic mode error handling is the easiest and therefore most common response to errors with or without exceptions, so it needs to be discouraged as an AntiPattern, not encouraged by saying "any exception that happens, just log it and be done" is a good general Design Pattern. (You didn't say that, I know.)
-- Anonymous
Drunken fight broken up; please keep moonshine to away from the BarnRaising.
I don't think anyone is arguing that programmers should log exceptions that should be handled in some other way.
The person who chose the name for this page is arguing against some hypothetical audience that does in fact claim this. So you are saying there is no such audience. So you are saying that this page should not exist.
But it is insufficient to say that it is self-evident, and therefore should not be said, that one should handle what should be handled, and if it can't be handled, log it. Even if that were all there were to the subject, it should still be said. If nothing else, it is good to note that some things can be handled rather than logged - a point which I have seen contradicted multiple times on this wiki, so don't say no one says that, they do.
And when I say "log", I mean send to the logging system. In the world I speak of that system monitored message severity and classification and paged the appropriate people. -- EricHodges
Obviously.
Perhaps this page should be renamed to NotifyingIsHandling
There appears to be two different things being discussed. One is whether the act of creating an entry in an error log is, by itself, sufficient to be called error handling. The other point is that notifying a support team to take manual intervention may be an appropriate manner in handling an error. The latter approach also recommends writing the error to a log. I think refactroing the name to fit the point might resolve the conflict. see LoggingIsNotHandling, LoggingDiscussion
EditText of this page
(last edited February 16, 2009)
or FindPage with title or text search