On Tue, 06 Mar 2012 11:34:21 -0600, Jose Armando Garcia
<jsan...@gmail.com> wrote:
On Thu, Mar 1, 2012 at 6:24 PM, Robert Jacques <sandf...@jhu.edu> wrote:
On Wed, 29 Feb 2012 18:13:30 -0600, 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.
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
The corollary to this is that causation is not clear from order. As I
posted in the other thread, I don't see a conflict between standardized
descriptive flags and a total ordering; in fact I think the flags help to
define the total ordering and improve logging consistency.
