On Wed, Mar 7, 2012 at 4:21 AM, Steven Schveighoffer <schvei...@yahoo.com> wrote: > On Tue, 06 Mar 2012 19:59:09 -0500, Andrei Alexandrescu > <seewebsiteforem...@erdani.org> wrote: > >> On 3/6/12 4:31 PM, Geoffrey Biggs wrote: >>> >>> On 07/03/12 09:25, Jonathan M Davis wrote: >>>> >>>> On Tuesday, March 06, 2012 13:08:42 Brad Roberts wrote: >>>>> >>>>> On Tue, 6 Mar 2012, Jose Armando Garcia wrote: >>>>>> >>>>>> Fix now: >>>>>> >>>>>> 1. Add thread name attribute to the default logger >>>>>> 2. Check that the example compile >>>>>> 3. Come up with a better name for Rich and rich template >>>>>> 4. Add @safe pure nothrow const to as many methods as possible >>>>>> 5. Remove check when setting Configuration.logger >>>>> >>>>> >>>>> I still believe pretty strongly that the logger must not affect >>>>> application flow, ie, not throw or exit the app. From the feed back, >>>>> I am >>>>> not alone in thinking that. I don't believe that "well, don't use those >>>>> log levels" is a workaround if for no other reason that there will be >>>>> libraries that contain them and that becomes a "dont use those >>>>> libraries >>>>> either" response. >>>> >>>> >>>> Agreed. The logging functions should _not_ throw. >>> >>> >>> +1. >>> >>> Is std.log a logging library or a complete error management library? >>> >>> If it's a logging library, the last thing it should be doing is >>> affecting program flow. In the case of fatal, in particular, the program >>> may need to do something else after logging the fatal error before >>> terminating. You could argue that the program should do that before >>> logging the fatal error, but I don't think that's nice semantics. >>> >>> On the other hand, if it's a complete error management library, it >>> probably shouldn't be called std.log. >> >> >> I don't see why the agitation around this particular matter. It's a matter >> of convenience, much like writeln (as opposed to just write). Let's admit >> that it often happens that you want to log some troublesome stuff just >> before throwing an exception with essentially the same message, so the thing >> is shown on the screen and also persisted in the log. Without a critical >> level, the pattern would be: >> >> string message = stuff() + ": " + moreStuff(); >> log.error(message); >> throw new Exception(message); >> >> It's nice to encapsulate this frequent pattern, hence: >> >> log.critical(stuff() + ": " + moreStuff()); >> >> If you want to log but not throw, use log.error. I don't think the >> response "dont use those libraries either" is meaningful. > > > I think access to the fatal/critical logging level should not be coupled > with throwing exceptions. I have no problem with having critical or fatal > convenience functions that throw and log, but it should not be a > *requirement*, and it should not be the default. > > I'd combine these two levels into one (there is no semantic difference > except one throws an exception and one throws an error), and if I got my > way, log.critical(...) would log a message and logAndThrow!(E = > Exception)(...) (name to be determined) would log a critical message and > throw the given exception/error with the same message. >
Yes, I am leaning toward this idea. Give me some time to come up with a better API that would make this logAndThrow template possible (we need to hint the Logger implementation that it needs to flush). Thanks, -Jose > -Steve
