Don't do it. Log files are a CodeSmell. ''(Note: This purpose behind this inflammatory statement is stated better in ExposeErrors.)''

'''or is it...'''

''You do not talk about Logging.'' -- DanielEarwicker (can't believe I only just thought of that...)

The first rule of logging is to ignore anonymous practical jokers. -- WillSargent

----

The second rule of logging might be - if you have to do it, consider integrating an adequate logging framework to minimize schedule risk.

If you are coding in Java, have a look at Log4J at http://jakarta.apache.org/log4j/docs/index.html.
Also see http://java.sun.com/aboutJava/communityprocess/jsr/jsr_047_log.html - Logging APIs to be included in Java (J2SE 1.4).

''This is one of two logging apis at jakarta-apache. The other is LogKit, part of the Avalon framework. There has been an ongoing spat between the authors over merging them; last time I looked there wasn't even a compatibility layer so you could reuse the contributed pieces. A real shame as they are both quality pieces of work. C'mon guys, sort it out???''
----

Clearly, the second rule is "Only log important stuff (for experts only)."  "Why that damn HeisenBug keeps happening" counts as "important stuff."

''The problem is that you do not know beforehand what is important.''

Not completely true.  You know some things that are important, but not everything.  For example, you know what you were trying to do, and something about what went wrong.  When something goes awry, you can start with "I was trying to do X, and I got Y."  "I was trying to delete file /boot/keepme, and I got 'Invalid moon phase.'"

''The knowledge of "what you were trying to do" is a sticky point. It doesn't seem important until something goes wrong. So you can either log conservatively to trace the error (a dubious practice) or you can somehow recover this knowledge at the point of logging information - e.g. a stack trace, or a history. A stack trace really says what you're going to do next, not what you were doing in the recent past.''

----
Third rule of logging: Aggregate errors.
Nobody wants to read 1000s of lines of ever repeating "mail cannot be delivered" or "user entered invalid data" or even worse "method x called".
Therefore (could be a pattern): Aggregate errors. Only report the first, 10th, 100th, ... occurence of the same 'cause' with a higher level.



----
ExposeErrors can mean
* expose to end-users. That is usually a bad idea except in very limited situations. 
* expose to administrators - in the end this is what a log-file does. Accumulating unread junk on disk.
* expose to developers - let them eat their errors as e.g. error mails

----
refactored to LoggingDiscussion
----
CategoryLogging