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