On Monday, February 13, 2012 23:58:38 Jose Armando Garcia wrote: > On Mon, Feb 13, 2012 at 4:19 PM, Jonathan M Davis <[email protected]> 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
