On 05/31/2011 09:29 PM, Steven Schveighoffer wrote:
On Tue, 31 May 2011 15:09:07 -0400, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
On Tue, 31 May 2011 14:48:57 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
I'm operating under the assumption that logCritical and logFatal are
at a different log level (i.e. the primary function of a logging
facility is to have different degrees of importance, which you can
turn on or off depending on the level set). Is that not the case? So I
can't have a situation where logError does nothing, but logCritical
logs a message?
Rereading the docs, it seems that fatal is actually a separate level, so
I still assert this is not a good design. I should be able to access all
levels without having the program abort or throw an exception.
I also note that critical is nowhere to be seen in the docs. Am I
missing something?
If we change fatal and critical to be the same level as error (and
enabled/disabled with error), I think it would be more sensible than
what you have proposed. It could be argued that it's not enough levels.
Typically, I've only needed 4 levels with logging:
fatal errors -- print a message then exit the application (gracefully!).
You cannot disable this level.
non-fatal errors -- print a message but the program continues.
info -- print a message for information so the flow of execution can be
followed (i.e. xyz logged in, xyz executed this program, etc.)
debug -- print all details, down to printouts of internal
structures/protocols.
I've never had much use for a warning level.
-Steve
I agree with Steven that terminating the app when logging a fatal
message is a horrible design choice. You would almost always want to
stop gracefully, witch you can't with the current fatal log.
A logging library should log messages, is shouldn't control the flow of
the application.
--
Mike Wey
