Review of Jose Armando Garcia Sancio's std.log

[Jose Armando Garcia]

On Tue, Mar 6, 2012 at 2:03 PM, Robert Jacques <sandford at jhu.edu> wrote:
> 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.

Please be explicit in what you are requesting... If you have an API even better.