On Tue, Mar 6, 2012 at 6:05 PM, Geoffrey Biggs
<geoffrey.bi...@aist.go.jp> wrote:
> On 07/03/12 09:59, 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.
>
>
> That approach means that if I actually do have a fatal error, I can't mark
> it as such. It gets conflated with the non-fatal errors, both in the source
> and in the logging output (which may, for example, be filtering for fatal
> errors to phone someone in the middle of the night while errors just send an
> email). Another point worth considering is that I cannot use the fatal level
> and be able to re-compile my software with logging disabled, because that
> will change the program flow.
>
Fatal and Critical severity cannot be disabled either at runtime or at
compile. In other words fatal log messages will always assert(true)
and critical log messages will always throw.
> Forcing the two semantic concepts (logging and error handling) together
> needlessly restricts the ways the library can be used. It is nice to
> encapsulate frequent patterns, but providing a convenience function that
> throws an error, or a new level ("terminate" or something) is a better
> approach than forcing that pattern on everyone. Based on the name, it's a
> *logging* library, not an error handling library.
>
Fatal and critical are these convenience functions.
> Geoff
