Review of Jose Armando Garcia Sancio's std.log
Jose Armando Garcia
jsancio at gmail.com
Fri Feb 17 10:06:01 PST 2012
On Thu, Feb 16, 2012 at 7:57 AM, Sönke Ludwig
<ludwig at informatik.uni-luebeck.de> wrote:
> Am 16.02.2012 10:21, schrieb Jonathan M Davis:
>> On Monday, February 13, 2012 16:50:04 David Nadlinger wrote:
>>> Please post all feedback in this thread, and remember: Although
>>> comprehensive reviews are obviously appreciated, short comments are very
>>> welcome as well!
>> Why does vlog even exist? It's a needless complication IMHO. Let the log
>> levels manage what does and doesn't get logged. I see no reason to add the
>> concept of verbosity on top of that. It's a needless complication.
>> Also, _please_ add a debug level. Personally, I'd argue for simply copying
>> syslog's levels and matching them, since ideally any logging on Linux
>> would be
>> going to syslog anyway. But there are good reasons to have messages beyond
>> info. I sure wouldn't want _all_ messages which don't indicate a problem
>> the app to be marked as info. For instance, what if I want to have info
>> displayed in release mode but want greater verbosity in debug mode? I'd
>> another log level which isn't there. Using the concept of verbosity to try
>> handle this is a needless complication. syslog has
>> #define LOG_EMERG 0 /* system is unusable */
>> #define LOG_ALERT 1 /* action must be taken immediately */
>> #define LOG_CRIT 2 /* critical conditions */
>> #define LOG_ERR 3 /* error conditions */
>> #define LOG_WARNING 4 /* warning conditions */
>> #define LOG_NOTICE 5 /* normal but significant condition */
>> #define LOG_INFO 6 /* informational */
>> #define LOG_DEBUG 7 /* debug-level messages */
>> And I'd like to at least see notice and debug added.
> Well in addition to Debug I would also like to see Trace but it's f. ex.
> hard for me to tell the difference between Info and Notice and their names
> do not imply that certain severity order IMO.
Yes. I would really like to avoid adding more severities because it
complicates the decision the developer needs to make when deciding at
which log level to log. This reminds of a situation that came up at a
previous employer. A bunch of smart people tried to come up with a
policy for deciding at which log level to log a particular message.
Let just say that the discussion lasted days and no decision was made.
I believe that the only reason why this subject even came up at my
previous job is because most logging framework provide hard-coded
levels that don't have any semantic difference between them.
Interesting talk on the subject:
> So I see a point in the
> argument that vlog() allows everyone to be happy without endless numbers of
> predefined log levels.. however I'm also not quite convinced.
>> While we're at it, what's the point of dfatal? Why on earth would a
>> condition not be fatal if it were in release mode if it were fatal in
>> mode? Is it fatal or not? It seems to me like another needless
>> If you're going to have write, then have writef, not format. Then it's
>> actually consistent with our normal I/O functions. Also, do writef and
>> automatically append a newline? If so, then they should be writeln and
> I think the names should be as short as possible for the common 99% case. As
> this is not a general purpose stream, I think it is fine to drop the 'ln'.
> And the current version that defines info("") as the version that can format
> and info.write("") as the plain string version seems to be quite optimal in
> this regard.
> In my optinion, more descriptive names would just impair readability here
> instead of helping. They will be written endless number of times but do not
> influence the program flow and should immediately understandable by anyone
> who sees them. But something like log.warn/logf.warn or log.warn/log.warnf
> might also work if you really want the consistency...
As of right now (or in the immediate future) we have:
info("%s message", Severity.info);
info.write(Severity.info, " message);
info.writef("%s message", Severity.info);
>> Rich is a horrible name IMHO. It says nothing about what it actually is or
>> does. I'm not sure what a good name would be (BoolMessage?, LogResult?),
>> Rich by itself is very confusing and utterly uninformative.
>> And why does Configuration's logger property throw if you set it after a
>> logging call has been made. Is it really that inconceivable that someone
>> swap out loggers at runtime? Or is the idea that you'd swap out the
>> - Jonathan M Davis
More information about the Digitalmars-d