On Sun, May 29, 2011 at 10:19 PM, Daniel Gibson <metalcae...@gmail.com> wrote: > Am 30.05.2011 03:07, schrieb Jose Armando Garcia: >> On Sun, May 29, 2011 at 9:37 PM, Daniel Gibson <metalcae...@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 <metalcae...@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 >>>>> >>> >>> > >