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.
