[slf4j-user] A problem with the lacking "exception" interface

[Ceki Gulcu]

Hello Matt,

Comments inline.

Matt Quigley wrote:
> I just wanted to suggest something, given that I have a problem with
> the given interface. To log an exception with SLF4J, we have:
> 
>  public void debug(String msg, Throwable t);
> 
> There is no "debug(Throwable t);" for reasons given at
> http://www.slf4j.org/faq.html#exception_message. However, what is
> given is a series of arguments telling me I don't know what I'm doing.

The arguments presented in [1] are imho objective and relevant to the
topic. I don't see any allusions to the personal qualities of the
reader/slf4j user, neither in substance nor tone.  I can understand why
you may not agree with the arguments but don't see how one could take
them personally. What makes you think that the arguments given are "a
series of arguments telling [you] don't know what [you are] doing"?

> I completely agree that a message should be given with exceptions,
> what I disagree with is that you have to pass in a String to do so.

OK.

> Not all exceptions are NullPointerExceptions, mind you. There is
> absolutely no reason I should have to pass a message to the logger
> with the following:
> 
> try {
>    ...
>    throw new MyCustomException("Table not found in the database", tableName);
> } catch (MyCustomException e) {
>    log.warn("Table not found in the database", e);
> }

Yes.

> Given that there is enough information in the exception to log an
> error appropriately, why is it that the interface forces me to do it
> the "good way (TM)"?  I mean, does adding that extra interface method
> really screw things up?  Will it slow things down?  Will it make users
> code clunky?  Is it SLF4J's way of making sure everyone is a good
> programmer? (I have a feeling that's the answer) One thing it
> certainly does is clutter up certain parts of my code unnecessarily.
> I can think of a few more reasons why I disagree with this.  Shouldn't
> the library be usable in all scenarios?  It's removing functionality
> that is already inherently in the library anyways!  The arguments say
> that removing this functionality is a good thing (TM), but I couldn't
> disagree more.


In the last paragraph of [1], "good thing (TM)" is meant humorously,
mostly in self-derision. All log4j-derived systems have aligned
themselves with log4j's requirements about logging exceptions --
that's just the way it is. Of course, saying "that's just the way it
is", is a pretty weak argument, hence the need for a like joke with a
reference to "good thing (TM)".

> I just thought that since you guys put a lot of thought into the
> interface, I'd tell you how it's affected me in my experiences of
> converting many of my company's projects from log4j to SLF4J.  BTW, I
> like SLF4J a lot better!

Thank you.

Users have been complaining about this issue for a long time. It's one
of log4j's, and by association, slf4j's, warts. Keep in mind that at
one point, slf4j, which was called "ugli" at the time, was supposed to
be 100% compatible with log4j. To make a long story short, 100%
compatibility is gone but the wart stayed. Now that SLF4J has a large
user base, we can't touch the slf4j API.


> -Matt

[1] http://www.slf4j.org/faq.html#exception_message

-- 
Ceki Gülcü

QOS.ch is looking to hire talented developers located in Switzerland
to work on cutting-edge software projects. If you think you are
qualified, then please contact ceki at qos.ch.