<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi Thomas.</div><div><br></div><div>On 29.09.2008, at 09:19, <<a href="mailto:Thomas.TH.Hamacher@partner.bmw.ch">Thomas.TH.Hamacher@partner.bmw.ch</a>> <<a href="mailto:Thomas.TH.Hamacher@partner.bmw.ch">Thomas.TH.Hamacher@partner.bmw.ch</a>> wrote:</div><div><div><div><br class="Apple-interchange-newline"><blockquote type="cite"> <div> <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></blockquote><div><br></div><div><div>Back in 2003 I was one of the guys that tried to persuade Ceki that log4j should support the trace-level that was available in commons-logging.</div><div><br></div><div>I guess I was pretty stubborn :p</div><div><br></div><div>Now, however, I think Ceki was right about his dislike of the trace level because tracing of an application is an orthogonal concept, i.e. if you'd like to have trace information it doesn't necessarily mean that you are interested in debug and info messages of the traced code.</div><div><br></div><div>When I first got in contact with slf4j it did only support debug, info, warn and error and I really liked the reduced amount of log levels because it reduced the ambiguity of logging.</div><div><br></div><div>I was a bit amused when trace was added to slf4j later ;)</div><div><br></div><div>One of the things that bothered me about the missing trace level back in 2003 was that I could actually think of a use for the trace level (i.e. tracing ;)) while I was absolutely unable to find a real use case for the fatal level.</div><div><br></div><div>If an error isn't fatal it's just a warning :p</div><div><br></div>Otherwise, with more than one level responsible for the "same" job, you just get different interpretations per developer, which is exactly what "We - for example - distinct the FATAL and the ERROR level in following logical units:" is all about ;)<div><br></div><div>That's also one of the reasons why I simply hate java.util.logging... the ability to register logging levels at will is a very bad idea, in my opinion.</div><div>Beside that, it's implemented in a terrible way (see <a href="http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java">http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java</a> for more details. While it's technically off-topic it's a very interesting and important read... jul is simply broken by design...)</div><div><br></div><div>Instead of using a fatal level, I'd instead suggest to just use a fatal marker if you absolutely need to differentiate between errors and more serious errors.</div></div><br><blockquote type="cite"><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.</font></div></div></blockquote><div><br></div><div>You are right that a switch from xyz logging to slf4j takes a bit more than simply changing the Logger and LoggerFactory class - but I'd really consider it a investment in increased software quality because of the reduced ambiguity (error/fatal) and also because I wouldn't consider logs that just contain a Throwable very good style. If you absolutely want them you can still get them simply by using an empty string as the message.</div><div>The slf4j api, on the other hand, does not encourage the omission of a clarifying message like it would if log methods that are just taking a Throwable would be provided.</div><br><blockquote type="cite"><div><div><font face="Arial" size="2"><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></blockquote><div><br></div><div>One could use the same argument to request arbitrary log levels like the ones supported by jul. slf4j shouldn't try to support everything other frameworks are providing.</div><div>Instead, I think it aims to be minimal but powerful nevertheless. </div><br><blockquote type="cite"><div><div><font face="Arial" size="2"> </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></blockquote><div><br></div><div>There simply is no real "standard-use" of error and fatal. Some use fatal only in the application layer, not in modules, while others would consider the inability to e.g. send an email fatal even though the application can just continue it's normal work.</div><div><br></div><div>I really understand your point - I switched a rather big project from commons.logging to slf4j some time ago - but I think the required amount of work is still quite manageable, a no-brainer most of the time and is absolutely justified by the increase in power and easy of use.</div><div><br></div><div>Just my 2 cent ;)</div><div><br></div><div>Joern.</div></div></div></div></body></html>