Review of Jose Armando Garcia Sancio's std.log

Robert Jacques sandford at jhu.edu
Tue Mar 6 10:11:49 PST 2012


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.


More information about the Digitalmars-d mailing list