Review of Jose Armando Garcia Sancio's std.log

[Jose Armando Garcia]

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.