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.
