Re: The usefulness of application logging
Greg Herlihy wrote:
I use logging as a diagnostic trace aid during development. But I leave
the logging code in when I deploy to production. I have come across
another way or working. This other way is to not bother logging
anything until there is a problem, then add logging to shed light on
Inexperienced programmers in particular often want to "see what the
program is doing" and thereby be able to reassure themselves that the
program is working as intended. And while application logging can be
used to verify a program's correct operation - more experienced
programmers know that application logging is almost always too
haphazard, error-prone and labor-intensive a techinque to be worth the
I have seen logging used in a way that was std-ized by the project:
this logging was neither haphazard nor error-prone; it was a useful
tool for shedding light on what the program was doing. It was used at
this high level, rather than for verifying that a given class was
working properly (we used unit tests for that). I agree that using
logging as a substitute for unit tests is the mark of an inexperienced
programmer, but that's not the kind of logging I had in mind. The value
of the logging in the project I am thinking of was during integration
testing. Sometimes we found problems during integration testing even
when all the unit tests passed. It was then we wanted to see the
interation between the classes. The logging we had enabled a flow of
control to be seen as well as useful intermediate calculation results.
the code of experienced programmers usually contains relatively little
in the way of logging the program's execution.
I have certainly seen many cases of the code from experienced
programmers containing few logging statements. This seems to outweight
the number of cases I have seen of experienced programmers that make
extensive use of it. I appreciate the time you have taken to shed light
on why this might be.
There are two principal shortcomings with application logging as a QA
technique: first, adding just the "right" amount of logging to a
program is often quite difficult.
Agreed. Though a decent logger that allows independent trace log levels
can help mitigate this. Don't seem to be many of those around though...
Second, interpreting the output can be a tedious and
error-prone task and - worse - is a task that depends upon knowledge
not present in the code but known only to a particular programmer. In
fact the XP school of programming even has a name for this approach:
the "guru checks output" anti-pattern.
Such code would fail the code review. Same as code that contained no
Concentrating on detecting errors turns out to have several advantages
as a QA technique over an approach that tries to detect correctness.
I do not consider logging to be the tools used to detect program
errors. Test tools are best used for that, IMHO. Once such a test tool
does detect a problem I think that logging can shed light on that
I would go so far as to say that there
are probably very few - if any - situations in which application
logging could not be more effectively and efficiently replaced with one
or more asserts.
I would point out that there are a few instances in which application
logging is useful: in particular, test code often logs a program's
state or output in order to compare against the expected state or
The unit test harness should assert expected results. If this includes
checking for certain output then it is useful if the output can be
assembled in a string, possibly by using streaming using an ostream.
Once the actual result is in a string it can be asserted against the
expected result. This enables the test to be an automated regression
test. The trouble with using logging for this is that it is awkward to
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]