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 log­ging is ef­fected with­out hav­ing called
>> this func­tion, all pa­ra­me­ters are at their de­fault val­ues and all
>> log­ging 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