std.log available for viewing

[Jonathan M Davis]

On 2011-05-29 18:19, Daniel Gibson 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).

assert(0) is normal without -release, but once you compile with -release, it 
becomes the HLT instruction. So, it kills your program when you hit in. The 
idea is that it should _never_ happen - even in release mode - and that if it 
does, you _want_ your program to be killed. For instance, dmd typically 
inserts assert(0) at the end of functions that are supposed to return a value 
so that it catches any cases where you reach the end of a function without 
returning a value (though it probably doesn't bother if the last line in the 
function is a return statement). If the program were to continue at that 
point, it would be in a fatal state, so assert(0) kills the program. Now, 
obviously, that's a case where the compiler does it, but there are plenty of 
other cases where you might find it useful in your own code (such as an else 
branch or a default case statement which should never be reached). I don't 
know where it is in the online documentation, if it's there at all. It is in 
TDPL though.

- Jonathan M Davis