<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.3395" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial
size=2>---------------->8-------------------------->8------------------------------->8--------------------<BR>Why
doesn't the org.slf4j.Logger interface have methods for the FATAL
level?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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.<BR>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.<BR>Assuming the
ERROR level designates exceptional situations meriting close attention, we are
inclined to believe that the FATAL level is
superfluous.<BR>---------------->8-------------------------->8------------------------------->8--------------------</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Hi @all,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>I would like to contribute some considerations to
the quoted statement from the slf4j-FAQ:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>I totally agree with you, that a logging-library
should not be responsible for terminating a programm. Furthermore a distinction
between an<BR>error and an "more-important"-error might be a little bit funny in
some cases, but anyways I would vote for a fatal-level.<BR>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<BR>and the ERROR level in following
logical units: errors, that are logged as FATAL are connected to the log4j. So
we - as administrators - would<BR>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<BR>it is sufficient to see them, when you daily scan your
logs. Therefore WARN would not be sufficient, because it is definately an
error.<BR>So this is a case, where the FATAL-level is very useful and I would
definately miss it in slf4j.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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<BR>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<BR>a logging library, that it supports at least everything I
already had before.<BR>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,<BR>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<BR>slf4j LoggingFactory. And then I should be done for the
moment.<BR>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).<BR>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.<BR>So shouldn´t it be your approach, that you
recommend some best-practices concerning logging and therefor have your special
methods to use best,<BR>but still support most of what that the "simple"
logging-frameworks already provide, so that the user is not forced to
refactoring? </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>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,<BR>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<BR>slf4j into exisiting-projects.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>What do you think about that?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>Thomas</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV></BODY></HTML>