Review of Jose Armando Garcia Sancio's std.log

[Jose Armando Garcia]

On Tue, Mar 6, 2012 at 5:07 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> On Tuesday, March 06, 2012 16:59:09 Andrei Alexandrescu wrote:
>> 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 that it would be far more meaningful to have a logging function which
> you pass the exception to throw.
This exactly how I am thinking of extending critical. I don't have an
API yet but the intent is that you can pass an exception to critical
and the module will throw it for you. Very similar to how enforce
works.

> That way, you can throw whatever is
> appropriate for your program, not have std.log throw a logging exception of
> some kind. Such a function would be a convenience function where the
> programmer is explicitly saying that they want to log and then throw rather
> than having logging functions throw as a matter of course if the logging level
> is critical enough. What if you want to log such a message _without_ throwing?
>
I think we are going around in circles. If you don't want to abort or
throw then use error.

> As it stands, std.log is conflating two separate concepts - logging and and
> error handling. Providing a convenience function to make that easier is fine,
> but making it so that the normal logging functions deal with error handling is
> not.
>
Fatal and Critical are exactly these continence functions... To
reiterate. fatal will always assert and critical will always throw. It
is impossible for the user to disable these things.

Thanks,
-Jose
> - Jonathan M Davis