Review of Jose Armando Garcia Sancio's std.log

[Steven Schveighoffer]

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.

-Steve