std.log available for viewing

[Daniel Gibson]

Am 30.05.2011 03:07, schrieb 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?
> 

Sounds ok, but for me it still "feels" strange that the logging library
terminates my program or throws exception. And error() (probably?) will
be logged differently than fatal(), even though both log an error and
fatal() has the additional feature to terminate your program via
assert(false); if I'm not mistaken.

[OT:] What is assert(false); supposed to do, anyway?
I think I've read it's supposed to terminates the program immediately
without any cleanups (which is unfortunate for a logging library - at
least destructors and scope guards should be executed so e.g. database
connections are cleanly closed).
I just tried it (with dmd 2.053 on linux) and it seems that normally an
AssertError is thrown on assert(false) (or assert(0)), but when compiled
with dmd -release I get a segfault..
Furthermore I couldn't find any documentation on the assert(0) special
case on the homepage (apart from posts in the NG).

Cheers,
- Daniel

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