Review of Jose Armando Garcia Sancio's std.log

Jonathan M Davis jmdavisProg at gmx.com
Mon Feb 13 18:02:06 PST 2012


On Monday, February 13, 2012 23:58:38 Jose Armando Garcia wrote:
> On Mon, Feb 13, 2012 at 4:19 PM, Jonathan M Davis <jmdavisProg at gmx.com> 
wrote:
> > On Monday, February 13, 2012 17:49:49 David Nadlinger wrote:
> >> You define the Severity enum members starting with fatal as 0. Why not
> >> the other way round – so that severityA < severityB would do what you
> >> (or at least I) would expect?
> > 
> > syslog defines 0 (LOG_EMERG) as the strongest and 7 (LOG_DEBUG) as the
> > weakest. The greater the number, the more logging output, you're going
> > to see. So, he's following syslog in that respect, though he doesn't
> > have as many log levels. He should probably add at least debug. He also
> > aliases them to module-level symbols for some reason, which is a big
> > no-no IMHO.
> 
> I am trying to minimize the number of predefined log levels. One of
> the big problems I see with having too many log levels is that the
> programmer never knows which one to use. I think std.log makes this
> very clear:
> 
> 1. Log at fatal if you want the application to assert
> 2. Log at critical if you want the thread to throw
> 3. Log at error if you detect a programming bug (invariant violation)
> but you wish to continue and cross your finger
> 4. Log at warning if you detected peculiar condition yet the program
> was coded to handle it.
> 5. Log at info if you want to document an action/state.
> 6. verbose log for trace/debugging specific parts of a program.
> 
> I think it would help me that instead of suggesting another level we
> instead state what we think the user would like to do or log but the
> framework as defined doesn't let the user do.

Personally, I'd just copy what syslog does in terms of log levels. Then 
std.log can use syslog and everything maps wonderfully.

- Jonathan M Davis


More information about the Digitalmars-d mailing list