On Wed, Feb 29, 2012 at 4:13 PM, Richard van Scheijen <dl...@mesadu.net> 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. > > I hope this helpful in the search for a good level system. >
Interesting observation on logging. I like your theoretical observation and explanation. To me the most important thing is usability and unfortunately people are used to log levels as a order concept. Meaning error is higher severity than info so if I am logging info events I should probably also log error events. If we go with a mechanism like the one you describe above there is no order so the configuration is a little more complicated or verbose I should say. Instead of saying we should log everything "greater" than warning the user needs to say that they want to log known-cause, known-effect, breaks-flow events. This mean that there are 27 (= 3^3) configuration combinations. To implement this we need 3 configuration nobs with 3 values (on, off, both). Thoughts? -Jose
