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

[Joern Huxhorn]

Hi Thomas.

On 29.09.2008, at 09:19, <Thomas.TH.Hamacher at partner.bmw.ch> <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: 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.

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.

I guess I was pretty stubborn :p

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.

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.

I was a bit amused when trace was added to slf4j later ;)

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.

If an error isn't fatal it's just a warning :p

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 ;)

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.
Beside that, it's implemented in a terrible way (see http://blogs.sun.com/fkieviet/entry/classloader_leaks_the_dreaded_java 
  for more details. While it's technically off-topic it's a very  
interesting and important read... jul is simply broken by design...)

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.

>
> 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.

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.
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.

>
> 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?

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.
Instead, I think it aims to be minimal but powerful nevertheless.

>
> 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?

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.

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.

Just my 2 cent ;)

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