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.

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

Reply via email to