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

[Ceki Gulcu]

Hello Thomas,

I agree with you that the existence of the FATAL level would make it easier for 
users to migrate to SLF4J from log4j or from commons-logging.

It was not clear to me how the FATAL level helped you. What do you mean by 
"errors, that are logged  as FATAL are connected to the log4j" ?

Cheers,

Thomas.TH.Hamacher at partner.bmw.ch wrote:
> ---------------->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: 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


-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch