Review of Jose Armando Garcia Sancio's std.log

[Jose Armando Garcia]

On Thu, Mar 1, 2012 at 4:59 PM, Sean Kelly <sean at invisibleduck.org> wrote:
> 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).

I liked Richard analysis but the truth is that I never needed that may
knobs for my logging needs. My thought process goes as follow:

I observed a interesting state:
1. Is the program observing external input for which the program can
execute around. E.g. parsing error with known default. If this is the
case the log warning.
2. Is the program observing a state that can do harm to the
system/computer/user. Log error and abort (std.log's fatal level) or
throw (std.log's critical level)
3. Is the program observing a state that would be interesting to
record for forensic. Log at info.

Think of a compiler parsing and generating CPU instructions for a
piece of code. If the compiler encounters an error in the code for
which it has no way to recover (missing symbol, etc), it logs an error
and aborts (exception or assert). If the compiler encounters a type
mismatch for which it can implicitly convert then maybe the compiler
will log a warning and continue. If the compiler wants to document
that it generated objects x, y and z then it can log at info.

Thanks,
-Jose