std.log available for viewing

[Steven Schveighoffer]

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.

It helps with the debug level to allow selectively turning on levels in  
certain areas.  For example, I had an application which was a tftp server  
as well as a server for another protocol.  When I was writing the TFTP  
portion, I needed to see the exact packets sent over the wire, but for  
TFTP only.  It was easy to do with log4net, I could just configure that  
class' logger to be at the debug level (without recompilation).  But I  
wouldn't consider such a feature a requirement for a logging library.  I  
think we should try and focus on the most common and useful aspects of  
logging for the built-in logger.  Seems similar to unittest -- good enough  
for most cases, and simple enough that it's used everywhere.

-Steve