Review of Jose Armando Garcia Sancio's std.log

Robert Jacques sandford at jhu.edu
Tue Mar 6 10:18:01 PST 2012


On Tue, 06 Mar 2012 11:34:21 -0600, Jose Armando Garcia  
<jsancio at gmail.com> wrote:
> 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

The corollary to this is that causation is not clear from order. As I  
posted in the other thread, I don't see a conflict between standardized  
descriptive flags and a total ordering; in fact I think the flags help to  
define the total ordering and improve logging consistency.


More information about the Digitalmars-d mailing list