std.log available for viewing

[Jose Armando Garcia]

On Tue, May 31, 2011 at 11:28 AM, Steven Schveighoffer
<schveiguy at yahoo.com> wrote:
> On Sun, 29 May 2011 16:57:52 -0400, Brad Roberts <braddr at puremagic.com>
> wrote:
>
>> On 5/29/2011 8:44 AM, Andrei Alexandrescu wrote:
>>>
>>> 1. The fatal log should never be stripped. This is because execution of
>>> code after using fatal depends on compile-time
>>> flags, which is unacceptable. Logging to fatal should terminate the
>>> application regardless of circumstances. Otherwise
>>> people would need to write things like:
>>>
>>> fatal("blah");
>>> assert(0, "Execution cannot continue even though logging is stripped");
>>>
>>> This is needless and bug-prone. Fatal is fatal.
>
> Fatal can be with context.  Let's say you have one thread that hits a fatal
> error, and another thread which is finishing out a DB transaction.  Since
> logging the fatal error will kill the whole application, I now would have to
> write some sync function that all threads have to periodically call to make
> sure I don't kill some perfectly valid process that's unrelated to the fatal
> error.  This seems like way more work to me than assert(0).
>
For some applications fatal makes sense for others critical is better
and for others error is better. Use the one that fits your application
or library. Having said that you can replace the assert(false) by
using a fatal handler the only requirement on this handler is that it
doesn't return or throw; otherwise std.log will assert(false).

>> At one time I used a log framework that included this behavior.  After a
>> couple years, I came to greatly regret it.
>> Fatalness down in libraries became overused, particularly in layers that
>> were libraries.  In some ways it was abuse of
>> fatal for things that shouldn't have been, but it's mere existence
>> encouraged it's use.
>>
>> I really don't think it's the log libraries job to implement app
>> termination behavior.
>
> Would it be possible to provide a "non-action" logger implementation?  It
> seems that the logger instantiation is customizable on the call to
> initializeLogging.  I'd say that should be the default as well (if you want
> certain actions, you can select the more proactive one).
>
This is not possible. Can you please motivate you requirement? The
intent is that some of the semantic of fatal, critical, error,
warning, info and verbose is set by the frontend to std.log and it
doesn't change when the user changes the backend. I want to give the
user some kind of guarantee on how the library behaves.

> Also, one thing I liked about log4net is that I could redirect certain log
> levels to different loggers.  That is, when I logged a fatal error, it went
> both to the log file and to the event log of the server.  Other levels
> simply went to the log file.  Is it possible to do stuff like that?  I admit
> I haven't fully read the docs, I just briefly read them.
>
Yes, we can do that in a future version with a configuration option
that logs to syslog in posix and event log in windows.

> -Steve
>