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.
That's my opinion as an uninformed user.
Geoff
