On 07/03/12 11:12, Jose Armando Garcia wrote:
On Tue, Mar 6, 2012 at 6:05 PM, Geoffrey Biggs
<geoffrey.bi...@aist.go.jp> wrote:
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.
OK, I took another look at the docs. I see your point now. Sorry for
making a fuss.
However, I think that in this case, the log levels usable without
killing the program are too coarse. This may be a matter of taste, though.
Geoff
