On Feb 29, 2012, at 4:13 PM, Richard van Scheijen wrote: > When logging the severity level should convey a certain insight that the > developer has about the code. This can be done with a 3 bit field. These are: > known-cause, known-effect and breaks-flow. > > This creates the following matrix: > > KC KE BF Severity > ================= > 1 1 0 Trace > 0 1 0 Info > 1 0 0 Notice > 0 0 0 Warning > 1 1 1 Error > 0 1 1 Critical > 1 0 1 Severe > 0 0 1 Fatal > > A known cause is when the developer knows why a log event is made. e.g.: if > you cannot open a file, you do not know why. > A known effect is when he/she knows what happens after. Basically, you can > tell if it is a catch-all by this flag. > > When a severity should only be handled by a debugger, the normal debug > statement should be used. This is in essence a 4th bit.
This is a really great breakdown of the log levels. I've never seen it explained so clearly. As a counterpoint, the important distinction I've found is primarily regarding what person should see a particular log line, and then only differentiated between INFO and ERROR messages. Roughly: * Developer-Trace * Developer-Info * Developer-Error * Admin-Info * Admin-Error * All-Fatal Typically, the Developer and Admin logs go to different locations, in which case the Admin log lines may be duplicated in the Developer logs to provide added context. In any case, what I've found is that with more than a few log levels, people typically don't know how to classify things, severity becomes arbitrary, and log-levels are rendered largely useless. So from the above, we have four severities: Trace, Info, Error, and Fatal, with flags to indicate what type of message is being logged: Developer or Admin (aka. User).
