in reply to Defensive Programming and Audit Trails

These are all things that I point out to my classes as much as I can. I try to explain how much help they can be, and I certainly hope that my students take my advice and use some type of logging in their applications.

Logging is something I add to pretty much any non-trivial program. Since most of my work falls into the non-Perl category, I've had to come up with different solutions over the years.

One place I worked had the coolest logging framework that I've seen. Each client (mostly VB, but some C) referenced a dll that exposed methods like Trace, Status, Alert and CriticalAlert.

Trace was for things that a developer wanted to see like SQL statements, variable info, etc.

Since our support people weren't developers, they would see all the status messages -- startup, shutdown, records inserted, updated and deleted.

If an alert log was written, an email would be generated and a CriticalAlert log would generate a page to the on-call support person.

The dll did a couple of would write a local log file and then broadcast the same information to a server where it was stored in a database. A service-type application would poll the database every n minutes and, depending on the severity of the error, would do nothing, email a list of people or send a page to the person on call.

It was very cool and I haven't seen anything like it since. I make sure I log things like startup, person logged in (username), things involving the data (inserts, updates, deletes) and then finally shutdown. Each entry is timestamped (do ya know how many times I've seen logs with no timestamp -- only the date?) and of course my log files are comma-delimited. It's amazing now many times I've seen people log in a format that is NOT readable with a text editor.


  • Comment on Re: Defensive Programming and Audit Trails