[slf4j-user] Some considerations about the FATAL-level

[Thomas.TH.Hamacher at partner.bmw.ch]

---------------->8-------------------------->8------------------------------->8--------------------
Why doesn't the org.slf4j.Logger interface have methods for the FATAL level?

>From the stand point of a logging system, the distinction between a fatal error and an error is usually not very useful. Most programmers exit the application when a fatal error is encountered. However, a logging library cannot (and should not) decide on its own to terminate an application. The initiative to exit the application must be left to the developer.
Thus, the most the FATAL level can do is to highlight a given error as the cause for application to crash. However, errors are by definition exceptional events that merit attention. If a given situation causes errors to be logged, the causes should be attended to as soon as possible. However, if the "error" is actually a normal situation which cannot be prevented but merits being aware of, then it should be marked as WARN, not ERROR.
Assuming the ERROR level designates exceptional situations meriting close attention, we are inclined to believe that the FATAL level is superfluous.
---------------->8-------------------------->8------------------------------->8--------------------

Hi @all,

I would like to contribute some considerations to the quoted statement from the slf4j-FAQ:

I totally agree with you, that a logging-library should not be responsible for terminating a programm. Furthermore a distinction between an
error and an "more-important"-error might be a little bit funny in some cases, but anyways I would vote for a fatal-level.
I just gave slf4j a try in my application and changed from standard-log4j to slf4j in favour of jcl. We - for example - distinct the FATAL
and the ERROR level in following logical units: errors, that are logged as FATAL are connected to the log4j. So we - as administrators - would
like to be immediately informed about any error, that occured in FATAL-level. Whereas errors in ERROR-level are logged into the log-file and
it is sufficient to see them, when you daily scan your logs. Therefore WARN would not be sufficient, because it is definately an error.
So this is a case, where the FATAL-level is very useful and I would definately miss it in slf4j.

But what I think is even more meaningful for slf4j is, that I would not say that using a logging-library should force a programmer to do a special
logging-logic in any way. You never know, what the backgrounds are, when people decided to use this or that logging-level, so I would expect from
a logging library, that it supports at least everything I already had before.
Imagine if people like me decide to migrate from one logging-library to another, because there might be some benefits over the existing logging-solutions,
all I would expect is, that I simply have to change the declaration of the logger. I my case, drop the log4j declaratation and change it to the
slf4j LoggingFactory. And then I should be done for the moment.
But what happended? I was not able to recompile my project, because of several limitations (for example no fatal-logging or no logging without a message but passing only the exception).
So I had to go through my code, rethink about it and do several adjustments. So this cost a lot more work, that I initially intended to raise.
So shouldn´t it be your approach, that you recommend some best-practices concerning logging and therefor have your special methods to use best,
but still support most of what that the "simple" logging-frameworks already provide, so that the user is not forced to refactoring?

If people like to use the benefits from slf4j (like the parameterized logging for example), it is up to them to use special slf4j-logic with the result,
that changing between the logging-libraries are somewhat more time-consuming, but for the standard-use it should be as easy as possible to integrate
slf4j into exisiting-projects.

What do you think about that?

Thomas


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://qos.ch/pipermail/slf4j-user/attachments/20080929/d5ab3ec3/attachment.htm>