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, [EMAIL PROTECTED] 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 _______________________________________________ user mailing list [email protected] http://www.slf4j.org/mailman/listinfo/user
