Review of Jose Armando Garcia Sancio's std.log

[Robert Jacques]

On Tue, 06 Mar 2012 13:41:32 -0600, Jose Armando Garcia  
<jsancio at gmail.com> wrote:
> On Tue, Mar 6, 2012 at 10:11 AM, Robert Jacques <sandford at jhu.edu> wrote:
>> On Tue, 06 Mar 2012 11:44:13 -0600, Jose Armando Garcia  
>> <jsancio at gmail.com>
>> wrote:
>>>
>>> On Tue, Mar 6, 2012 at 9:32 AM, Robert Jacques <sandford at jhu.edu>  
>>> wrote:
>>>>
>>>> On Tue, 06 Mar 2012 11:01:19 -0600, Jose Armando Garcia
>>>> <jsancio at gmail.com>
>>>> wrote:
>>>>
>>>>> 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
>>>>
>>>>
>>>>
>>>> There are only 8 possible configurations and they are nicely ordered  
>>>> in
>>>> terms of severity. So I don't see this as a problem. Also, if you went
>>>> with
>>>> a combinatorial approach, shouldn't it be 2^8 = 256, not 3^3 = 27  
>>>> values?
>>>
>>>
>>> Yes. If you want to enable and disable each individual "level" then
>>> you need 8 configuration options which leads to 2^8.
>>>
>>> I suggested 3^3 as a more reasonable options that matches how the
>>> developer is logging but doesn't give you as much expressiveness as
>>> the 2^8 option.
>>
>>
>> In practice, all you'd need to take is a flag with the desired levels.  
>> i.e.
>>
>> // Automatically set logging levels using the standard severity ordering
>> config.minSeverity(Severity.Warning);
>>
>> // Manually set the logging levels
>> config.setSeverities(Severity.Warning|
>>                     Severity.Error|
>>                     Severity.Critical|
>>                     Severity.Severe|
>>                     Severity.Fatal);
>>
>> I don't see the problem with including both methods and a large  
>> advantage to
>> having a standardized severity framework.
>
> Interesting. If you find this useful, I think we can add this in a
> future release as it shouldn't break existing modules that maybe using
> the library.

This began as a discussion regarding Richard's organization of logging  
severity. That organization isn't something that can be trivially included  
at a later date.