std.log available for viewing

[Daniel Gibson]

Am 30.05.2011 02:11, schrieb Jose Armando Garcia:
> Then use critical with all the exception handling techniques that D
> provide, try, scope, etc. Maybe critical should allow the throwing of
> user define exceptions with a meaningful default. What do people
> think?
> 

I don't have much experience with logging frameworks, but is there
really a *need* for a fatal log-function that terminates the program?
I'd expect fatal() to produce a line like "<timestamp> FATAL:
<yourmessage>" in the log (and I'd expect it to be logged when only
fatal messages are activated) - but I wouldn't expect it to terminate
the program. I'd just like to log the fatal error (yes, it is fatal, not
just critical or something) and terminate the program myself.

BTW: You may have noticed that people in this newsgroup usually write
*below* the cited text they're referring to - could you do the same, for
the sake of consistency and readability?  Thanks :-)

Cheers,
- Daniel


> On Sun, May 29, 2011 at 6:20 PM, Daniel Gibson <metalcaedes at gmail.com> wrote:
>> Am 29.05.2011 22:57, schrieb Brad Roberts:
>>> 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.
>>>
>>> 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.
>>>
>>> My 2 cents,
>>> Brad
>>
>> Also imagine the following scenario: You detect a fatal error and want
>> to log it, while all the useful information you want to log is at hand.
>> However afterwards you'd like to shut down the application gracefully to
>> leave your data as consistent as possible or whatever, so you don't want
>> the application to terminate immediately after fatal() but you want to
>> do error handling yourself and terminate afterwards (and what you do for
>> error handling/shutting downmay be dependent on the error, so just using
>> scope(error) may not be the easiest choice).
>>
>> Cheers,
>> - Daniel
>>