std.log available for viewing

[Jose Armando Garcia]

On Sun, May 29, 2011 at 10:19 PM, Daniel Gibson <metalcaedes at gmail.com> wrote:
> 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).
>
http://d-programming-language.org/expression.html#AssertExpression

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