Review of Jose Armando Garcia Sancio's std.log

[Jose Armando Garcia]

On Wed, Mar 7, 2012 at 4:21 AM, Steven Schveighoffer
<schveiguy at yahoo.com> wrote:
> On Tue, 06 Mar 2012 19:59:09 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail at 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.
>

Yes, I am leaning toward this idea. Give me some time to come up with
a better API that would make this logAndThrow template possible (we
need to hint the Logger implementation that it needs to flush).

Thanks,
-Jose

> -Steve