Early review of std.logger

[Jeremy Powers]

Comments on comments.  And to be clear, this is just me wanting everything
to be amazing - I'm incredibly glad to have any logging framework at all,
and will use what I can get.

 >> Allow custom info to be inserted based on logger context.
 > don't think that this is a good way to good, complexity and speed wise.

Configurable/custom logging output is required for (most) complicated
systems.  Aside from having to fit into a pre-existing log format, think
logging a request id for every action that happens within the context of a
request.  You can manually plum in the info everywhere and pass it to the
logger, but it is much easier/cleaner to be able to set info on a logger
context.  For some cases this is the only reasonable option.
Like: http://logback.qos.ch/manual/mdc.html

>> * Pass an exception to logger directly, have it output in message
>> depending on configuration.  Pretty vs. short vs. all-one-line for
>> automated log parsing.
> I think format("%s", someException) already calls toString on
someException (I need to this.)

I'm thinking of cases where the standard exception toString may not be
appropriate, like when you need every log statement to occur only on one
line for log parsing, perhaps with a shortened stack trace.  But still want
to be able to run the same code in development and be able to look at logs
without eyes bleeding.  It might be useful to include the API to take an
exception directly, even if it doesn't actually do anything special without
a custom logger implementation.
Like:
http://logback.qos.ch/apidocs/ch/qos/logback/classic/Logger.html#error(java.lang.String,
java.lang.Throwable)


> MultiLogger will come.

Excellent.
Obligatory logback link: http://logback.qos.ch/manual/appenders.html


>> * The 'critical' level seem extraneous - when would you use this instead
of error or fatal?
 > The system has tripped bad. Maybe some config file is not there, but
some system env might to the trick.

If you have encountered a problem, is an error.  If you can't recover, is a
fatal.  I can't think of a time when I would want to use critical where an
error or fatal wouldn't be appropriate... personally, I'd rather have an
explicit debug/trace level instead.

>> * Easy way to create logger per module, inheriting settings from logger
hierarchy.
>> Associated way to manage loggers and their configuration.
>
>module myModule;
>Logger myModuleLogger;
>static this() {
>    myModuleLogger = new StdIOLogger();
>}

Yes, but.  Should be able to create a logger per module, and have it
automatically fit into log hierarchy for configuration.  Example:

module foo -> has logger foolog
module foo.bar -> has looger barlog, child of foolog

Want to be able to configure log levels on foolog and have barlog inherit.
 Useful for turning on/off log levels for my code but not changing log
output from code I pull from elsewhere.  I'd say this is one of the most
critical parts of an effective logging framework.  Making it easy/default
gains a lot.
Like: http://logback.qos.ch/manual/architecture.html


Also:
I like log.error(foo) better than log(error, foo).  And the shed should be
blue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131014/ead034c1/attachment.html>