On Thu, Mar 1, 2012 at 6:24 PM, Robert Jacques <[email protected]> wrote: > On Wed, 29 Feb 2012 18:13:30 -0600, Richard van Scheijen <[email protected]> > 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
