Re: (cLive ;-) Re: Performance quandary

I suspect many will agree with me that logging is ALWAYS absolutely necessary. You will never be able to prove that your implementation of a non-trivial system "works". Ever. You can get to 99.9%, but you will always have that uncertainty. Always. Logging is the simplest method by which you, as the developer, can have an idea of what went wrong when (not if!) it does break.

Never assume that a system a human develops will not break. Even if the human's activity was to write the code that wrote the code ... there's still an error in there. Somewhere.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Comment on Re: (cLive ;-) Re: Performance quandary

Replies are listed 'Best First'.
Re: Re: (cLive ;-) Re: Performance quandary by SwellJoe (Scribe) on Feb 26, 2002 at 15:30 UTC
Thanks dragonchild! I've been getting a lot of 'get rid of logging' or 'let BerkeleyDB handle logging'. But neither of those answers the problem of how do I let a user help me debug any problem that might arise once it is out of my control. It is true that logging calls were quite rampant in the first incarnation of the program (and most unnecessary calls are gone now that the program is known to work in all common-cases that I can generate). But some logging is still absolutely necessary, and I'm actually quite proud of the way I've implemented logging for this trivial little program. I ripped off, er, reused a nice little logging class written by Jeff Rowan, found here: http://jrf.odpn.net/writings/200011plog.shtml And then added a loglevel value, so that the user (who has a configuration file for runtime changes to the system, of course) can increase the loglevel if problems arise. Ordinarily, logging is quite brief, and the calls to $log->print simply return after checking against the current loglevel. Pretty nifty (the ", 3" at the end of all of the logging statements is the loglevel for this entry--so it is a debug level log rather than a user level log).	[reply]

Replies are listed 'Best First'.

Re: Re: (cLive ;-) Re: Performance quandary
by SwellJoe (Scribe) on Feb 26, 2002 at 15:30 UTC

I've been getting a lot of 'get rid of logging' or 'let BerkeleyDB handle logging'. But neither of those answers the problem of how do I let a user help me debug any problem that might arise once it is out of my control.

It is true that logging calls were quite rampant in the first incarnation of the program (and most unnecessary calls are gone now that the program is known to work in all common-cases that I can generate). But some logging is still absolutely necessary, and I'm actually quite proud of the way I've implemented logging for this trivial little program.

I ripped off, er, reused a nice little logging class written by Jeff Rowan, found here:

http://jrf.odpn.net/writings/200011plog.shtml

And then added a loglevel value, so that the user (who has a configuration file for runtime changes to the system, of course) can increase the loglevel if problems arise. Ordinarily, logging is quite brief, and the calls to $log->print simply return after checking against the current loglevel. Pretty nifty (the ", 3" at the end of all of the logging statements is the loglevel for this entry--so it is a debug level log rather than a user level log).

[reply]