On Tue, 06 Mar 2012 13:41:32 -0600, Jose Armando Garcia
<jsan...@gmail.com> wrote:
On Tue, Mar 6, 2012 at 10:11 AM, Robert Jacques <sandf...@jhu.edu> wrote:
On Tue, 06 Mar 2012 11:44:13 -0600, Jose Armando Garcia
<jsan...@gmail.com>
wrote:
On Tue, Mar 6, 2012 at 9:32 AM, Robert Jacques <sandf...@jhu.edu>
wrote:
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?
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.
