Review of Jose Armando Garcia Sancio's std.log

Jose Armando Garcia jsancio at gmail.com
Tue Mar 6 09:01:19 PST 2012


On Wed, Feb 29, 2012 at 4:13 PM, Richard van Scheijen <dlang at 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


More information about the Digitalmars-d mailing list