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 <[email protected]> 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
