Implementing std.log
Michel Fortin
michel.fortin at michelf.com
Sat May 14 16:43:26 PDT 2011
On 2011-05-14 18:35:32 -0400, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> said:
> On 05/14/2011 04:56 PM, Michel Fortin wrote:
>> I'll also question whether they should be written to files at all by
>> default (as opposed to stdin and stderr). I'm aware initLogging's
>> documentation says: "If logging is effected without having called
>> this function, all parameters are at their default values and all
>> logging is done only to stderr." So basically, I'll get what I want if
>> I never call initLogging, but then I can't control verbosity and other
>> settings using --v and other flags passed as arguments.
>
> A server app must log to files, no question about that. We'll need to
> add rotation etc. in the future.
No question about that.
What I'm questioning is whether the typical use case for logging will
be a server app. Ideally, I think we should encourage people to add
logs everywhere it makes sense, if only as a debugging aid. If the
default behaviour is to write logs to files it starts to look like a
specialized tools for servers and such and it appears less relevant for
other use cases.
> But I do plan to offer ways to manually override defaults, e.g.:
>
> void main(string[] args)
> {
> logtostderr = true; // override default
> initLogging(args);
> ...
> }
The default value for "logtostderr" should be reversed. Let's not make
a server application the default use case for std.log, shall we? Even
if that was the idea, the default is currently to save files in /tmp
(or equivalent), which does not seem very appropriate for a server to
me.
I think logging to files should be enabled only explicitly by providing
the default logging directory as an argument:
initLogging(args, "/logdir");
--
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/
More information about the Digitalmars-d
mailing list