std.log available for viewing

[Steven Schveighoffer]

On Tue, 31 May 2011 14:10:20 -0400, Jose Armando Garcia  
<jsancio at gmail.com> wrote:

> On Tue, May 31, 2011 at 2:34 PM, Steven Schveighoffer
> <schveiguy at 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