std.log available for viewing

[Jose Armando Garcia]

On Sun, May 29, 2011 at 9:37 PM, Daniel Gibson <metalcaedes at gmail.com> wrote:
> 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.
>
It is just a matter of semantic. We have, if you want, arbitrarily
defined fatal to halt the program, critical to throw an exception, and
error to just log. But we should think of them all as an error/bug in
your program. Now if in a particular point of your application you
want it to halt on such error then use fatal, if you want it to throw
then use critical, if you want it to just log then use error. The
power is in your hand. Fair enough?

> 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 :-)
>
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
>>>
>
>