std.log available for viewing

[Mike Wey]

On 05/31/2011 09:29 PM, Steven Schveighoffer wrote:
> On Tue, 31 May 2011 15:09:07 -0400, Steven Schveighoffer
> <schveiguy at yahoo.com> wrote:
>
>> On Tue, 31 May 2011 14:48:57 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at 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