Voting: std.logger

[Kevin Lamonte via Digitalmars-d]

On Monday, 1 September 2014 at 10:43:34 UTC, Ola Fosheim Grøstad 
wrote:

> I guess the most robust solution is to use shared memory and 
> fork, when the child dies you soup up the log and upload it to 
> a logging-server.

I'm used to a centralized system taking logs on a continuous 
basis, with "normal, I'm happy" messages coming through in a 
regular interval.  When the application dies, it already has had 
its messages emitted and sucked up by the collection system, and 
if its heartbeat messages aren't seen then people are prompted to 
investigate anyway.  It's on the main server (e.g. syslog or 
LogStash) to handle storage space issues like log rotation.

> I am also interested in lazy formatting, meaning you log a 
> reference to the immutable formatting string and the 
> parameters, but wait with the formatting until the result is 
> needed.

log4d does this, it saves the Logger+LogEntry references and only 
applies PatternLayouts at the end, BUT it does so with the risk 
that additional fields specified in the conversionPattern might 
be wrong since they were not generated/evaluated in the context 
of the original log call.  Thread ID (%t) is the main culprit 
(since it is not in LogEntry, PatternLayout has to get it), but 
also time between log calls and time since application startup 
(%r/%R).

But it sounds like you want std.logger to not apply formatting 
even in its infof/errorf/etc functions.  That might be a problem 
for things like the number of rows in a result set, the current 
time, or the remote system hostname.  For example, by the time 
the logging infrastructure evaluates the number of rows, the 
result set is long gone and could throw an exception.  I would 
argue that this kind of lazy evaluation would be fine if it was 
not enabled by default.