Review of Jose Armando Garcia Sancio's std.log

Jose Armando Garcia jsancio at gmail.com
Tue Mar 6 14:21:48 PST 2012


On Tue, Mar 6, 2012 at 1:08 PM, Brad Roberts <braddr at 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
>


More information about the Digitalmars-d mailing list