On Tue, 31 May 2011 14:10:20 -0400, Jose Armando Garcia
<jsan...@gmail.com> wrote:
On Tue, May 31, 2011 at 2:34 PM, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
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.
That is probably because most programmers write web application in
which independent request/processing are all handle by the same
process. So by definition since requests are independent it is unfair
for one request to affect another request (by asserting) because they
share the same process. Not everyone writes application using that
model. If your programming model is such (or architecture if you
prefer that word ;), then yes using fatal("") is not wise but maybe
critical("") and error("") is.
If critical throws, then it is also of no use. I want to control when
exceptions are thrown, I don't want exceptions or program halting to be
the tax for using the logging facility.
I can see this pattern emerging:
try
{
logCritical("critical error encountered!");
}
catch(Exception e){} // stupid std.log...
Let say instead you are writing a multi-process embedded system for
the mars-rover and your subsystem deals with propulsion then maybe you
do want to fatal("") or assert(false) instead of driving down a cliff
even though the camera sub-system wants to take a picture of a pretty
rock.
Then I do assert(0) instead? Why the fuck do I bother logging? Assert as
soon as possible to avoid falling off a cliff!
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?
This is a matter of who makes the decision and has the domain
knowledge. I say that the decision if something should assert or throw
or just logs is up to the module coder. The coder that wrote fatal("")
for example. Not the person that configures the logger/writer which in
many systems knows nothing about the intricacies of the application or
modules.
Again, one has the ability to do fatal(""); assert(0); or
myFunctionThatLogsThenAsserts("");
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.
As a exercise, try to write such a function that gives you the same
flexibility of std.log. E.g. willLog, when(), compile time disabling,
etc. and I think you will end up with something similar to std.log!
I'm not complaining about anything but the assert(0) and throwing an
exception on fatal and critical error respectively. The other facilities
I haven't examined, but sound reasonable to me.
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.
I would like to be flexible and meet your requirements but what is the
problem of not using fatal if you don't want to assert and not using
critical if you don't want to throw and instead use error if you just
want to log?
Because some shmuck will use fatal or critical in a library function, not
understanding what a grave mistake it is, and then I have to go pester
them to change it. If the #1 rule of std.log is don't use fatal, because
it can kill your program, then I think why is it there?
You are conflating logging a fatal condition with destroying the program.
The two functions are separate, and I would argue that a log level should
not be reserved for cases where you want to assert(0) or throw an
exception. You can create an additional function that ties these together
so easily, I can't understand why we are having this debate.
-Steve
