in reply to When to use logging and why?
First wearing my User Hat, logging is a Good Thing because when the application goes wrong - and *all* software goes wrong at some point - it means that when I whine at the developer I can accompany my whine with information he will find useful for hunting down and fixing the bug.
And wearing my Developer Hat, given that my users are going to whine at me - and *all* users whine at some point - I want them to be able to whine intelligently. Not to mention that logging is very handy indeed for debugging the rubbish I write before I release it on an unsuspecting world.
Given those reasons *why* to use it, answering the *when* becomes easy - you should log *always*. Make your application log by default, allowing the user to turn logging off if they really care.
The question you don't ask is *what* to log. I like to log all significant events, with a timestamp, and with some indicator of how important the event is - is it an informational notice? a warning? a failure? debugging info? Release your app with debugging turned off, but all other log levels turned on, and as well as allowing the user to turn all logging on or off, it's nice to let them turn the log level up and down.
An example of a notice would be "constructor method called with parameters FOO BAR BAZ". A warning might be "constructor called with invalid value FOO for parameter BAR". A failure might be "failed to serialise object to disk". Debugging info would be hideously verbose, like for each subroutine, logging entry parameters and return values. Log files should be formatted both to be easily searchable (find all warnings in the Foo module) and easy to read. Whitespace and indentation is Good.
|
|---|