On Tue, 31 May 2011 12:28:12 -0400, Jose Armando Garcia
<jsan...@gmail.com> wrote:
On Tue, May 31, 2011 at 11:28 AM, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
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).
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).
Again, this sounds way too complicated for what it's giving you (avoiding
having to forcibly kill your application if that's what you desire). If I
had to choose from your options, I'd use neither critical nor fatal. I'd
probably just stick with the higher levels, and start putting my own
levels in as strings to avoid what I'd consider to be "buggy" behavior...
From my own experience, I almost never *never* use a forced kill. A
graceful shutdown works much better. Remember that a 'fatal' error is not
so much a "this program can't continue because it's not sane," but a "this
program cannot continue because something is misconfigured, etc." This
does not warrant raw destruction.
A better option is to make the default "handler" assert(0), and let you
override that when you set a new one. This should not be too difficult
(only need assert(0) in one place).
Flexibility in this regard is way more valuable than consistency between
applications. I don't see the reasoning for the hard requirements. Is it
simply because it's this way in glog?
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.
Sure, the requirement is that the logger never ever alters my program's
behavior without my permission. I'm using the logger to log data, not to
create code paths. If I want a function that logs a message and then
halts the application, I can write one of those (you can even include it
as part of std.log!). It's like having fopen halt your application if it
can't open a file.
Essentially I think it is an egregious mistake to tie whole-application
functionality to logging. I don't care of the convenience, a logger is
for logging, nothing else. For sure, if std.log implements mandatory
halting, my belief is another competitor log library will certainly get
the lion's share of users, even if it's third party.
-Steve
