Re: The usefulness of application logging
Greg Herlihy wrote:
James Kanze wrote:
Greg Herlihy wrote:
apm35@student.open.ac.uk wrote:>
I wonder what use people make of logging generally.
Perhaps people can share their experiences and opinions
here. Surely there is more than just these two ways of
doing it.
This following is not meant to be a criticism of anyone,
but I have found that inexperienced programmers are
usually the ones whose code makes heavy or systemic use of
application logging as a QA technique.
I've found just the contrary. It's inexperienced
programmers who don't realize just how useful it can be, and
simply suppose that it will be too expensive. Experienced
programmers generally log pretty heavily. (I know that I've
consistently increased the amount I log as I've gained
experience.)
Regardless of the amount of application logging a programmer
may perform while writing a program (which is a matter of
personal preference),
More likely a question of programming guidelines (and in some
extreme cases, legal issues).
I would expect that the more experienced programmer would be
more likely to remove all logging code once work on the
program had completed.
Your expectations don't conform with reality. In practice, the
more experienced a programmer is, the more likely he is to leave
a maximum of logging in the deployed program. (Provided there
exists some possibility for him to access the log files later.)
After all, the purpose of the logging code is aid development,
so once development is over, the logging code has necessarily
outlived its usefulness.
That's superficially true. But development is only over when
you can be 100% sure that there are no more errors in the code.
That is: never. And logging, as a development aid, is most
important in deployed code, where there are very few other
development aids.
The logging code in a finished program becomes simply a
liability: potentially impairing the program's efficiency, its
stability or even its security.
You'll have to explain that one to me. I've always designed my
logging systems so that they can be compiled out if necessary,
but I've never had to compile them out---a well designed logging
system does not create significant additional overhead when it
is configured to lower levels of logging. As for stability or
security: changing anything from the development version (the
version which was tested) greatly reduces both stability and
security. If you have logging in development versions, then you
should only remove it from the production version under dire
necessity.
Just to be clearthat this
discussion concerns only developer-added logging - that is,
logging that is not part of the program's specification. Many
programs do maintain logs of their own activities as part of
their routine, planned operation - and that is not the type of
logging being discussed here.
I'm not sure where, or even if, you can draw the line. My
logging systems typically have 9 or 10 different levels. (No
great philosophical reason; you really only need 4 or 5. 9 or
10 just happens to be what you get if you use a single digit to
specify the level.)
In reality, the problem is not so much leaving extraneous
logging code in a finished program - the problem is really
ever adding logging code the program in the first place.
Logging code really belongs somewhere else. After all, the
purpose of logging is to document a program's state at a
particular point - and to capture that information should be
possible without having to change the program itself.
Exactly. And since we have to be able to do it in a deployed
program, what other solution do you recommend?
By modifying the program in order to log its execution, the
program being logged is no longer identical to original
program or the program as it will ship.
Exactly. That is, IMHO, a killer argument for leaving the
logging in a deployed program.
In order to obtain logs as accurate as possible, the logging
should be conducted as part of the program's execution
enviroment.
You can't usually control the execution environment.
Running the program under a debugger, and configuring the
debugger to output the information of interest accomplishes
that goal quite handily.
Asking your users to run the program under a debugger isn't an
option on the programs I've worked on.
Having the debugger generate the program's execution log
allows the programmer maximum flexiblity in obtaining the
information of interest - and to do so without ever having to
alter the program under observation. And by keeping separate
the data collection and the program's execution logic, there
is no danger of any logging code winding up in the finished
product where - at the very least - it is of no value to the
user running the program (since a user generally wants to run
a shipping program for some purpose other than to debug it).
And experienced programmer know that regardless of what they
want, the users always do end up doing some of your debugging.
At the very least, you can never be 100% sure that this isn't
the case.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]