Re: Defensive Programming and Audit Trails

in reply to Defensive Programming and Audit Trails

I've recently wrote a program in which I used extensive logging. It was a C program, but the principles remain. I didn't use multiple -v flags to indicate what to log, but instead, I logged everything with syslog (the program is run as a daemon, so syslog is a natural choice). The advantage of logging with syslog is that you can configure outside of the program what you will keep. And very importantly, you can change what you are interested in without restarting the program. Furthermore, you can decide to keep errors in a separate file, which you retain longer than say, notices.

Abigail

Comment on Re: Defensive Programming and Audit Trails

Replies are listed 'Best First'.
Re: Re: Defensive Programming and Audit Trails by agentv (Friar) on Aug 06, 2002 at 19:01 UTC
...This last is a good point. It is not necessary to dump all of your messages into a single log file. One very elegant strategy I encountered recently was to maintain a separate file for messages of each severity level. Imagine a set of message severity levels: chatter progress information warning error If we use "information" as the default logging level, we would produce three output log files. If the end-user selects a higher level of logging, then files for that severity level would be updated too. In this software, the designers also had log information sent to STDERR so that you could observe if you felt like it. The syntax model for the command line was like: `program [-nostderr] [-loglevel <severity>]` [download] As an administrator of that software, I appreciate the ability to ask for as much (or as little) information as I need. I try to write my own programs in that same fashion. ...all the world looks like -well- all the world, when your hammer is perl. ---v	[reply] [d/l]

Replies are listed 'Best First'.

Re: Re: Defensive Programming and Audit Trails
by agentv (Friar) on Aug 06, 2002 at 19:01 UTC

It is not necessary to dump all of your messages into a single log file. One very elegant strategy I encountered recently was to maintain a separate file for messages of each severity level.

Imagine a set of message severity levels:

chatter
progress
information
warning
error

If we use "information" as the default logging level, we would produce three output log files. If the end-user selects a higher level of logging, then files for that severity level would be updated too.

In this software, the designers also had log information sent to STDERR so that you could observe if you felt like it. The syntax model for the command line was like:

program [-nostderr] [-loglevel <severity>]
[download]

As an administrator of that software, I appreciate the ability to ask for as much (or as little) information as I need. I try to write my own programs in that same fashion.

...all the world looks like -well- all the world, when your hammer is perl. ---v

[reply]
[d/l]

In Section Meditations