On Sun, 29 May 2011 16:57:52 -0400, Brad Roberts <bra...@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).
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).
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.
-Steve
