Review of Jose Armando Garcia Sancio's std.log

[Jose Armando Garcia]

On Thu, Mar 1, 2012 at 6:24 PM, Robert Jacques <sandford at jhu.edu> wrote:
> On Wed, 29 Feb 2012 18:13:30 -0600, 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.
>>
>
> vote++
>
> I think establishing a good guideline as to log usage should be part of
> std.log's documentation. Making the bitflags a part of Severity might help
> cement this concept. It would also allow self documenting code, like:
>
> log!(knownCause|unknownEffect|breaksFlow)("This is a severe message.");

Alluded to this before. My concern with this is that order is not
clear from the usage. And if we want to configure logging with a
mechanism that doesn't support ordering that means that the user will
need 3 knobs to configure each with 3 possible values.

Thanks,
-Jose