On Tue, 06 Mar 2012 11:01:19 -0600, Jose Armando Garcia
<jsan...@gmail.com> wrote:
On Wed, Feb 29, 2012 at 4:13 PM, Richard van Scheijen <dl...@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?
