On Tue, Mar 6, 2012 at 1:08 PM, Brad Roberts <bra...@puremagic.com> wrote:
> On Tue, 6 Mar 2012, Jose Armando Garcia wrote:
>
>> Future:
>>
>> 1. Allowing filtering of regular log messages (like info, warning,
>> etc) based on the module. Similar to how vlog works.
>
> Once you add module filtering to the regularly log messages, what's the
> point of having the separate vlog? I think this needs to be figured out
> before merge, not at some vague future.
>
>> 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.
>
Yeah. I completely understand your point. I don't have a technical
argument for adding or removing fatal and critical. The only advantage
is that the developer is explicitly telling the logging framework when
the application will/may terminate. Instead of everyone having to
write:
void critical(...) {
log.error(...);
// force a flush. currently there is no way of expressing this so we
need to put this
throw new ...;
}
and:
void fatal(...) {
log.error(...);
// force a flush. currently there is no way of expressing this so we
need to put this
assert(true);
}
> My 2 cents,
> Brad
>
