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

[Matt Quigley]

> 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 was not taking them personally. My point is that the argument says
that "this is the way we think it should be done, logging exceptions
should be accompanied by a contextual message, so you have to do it
this way with our interface, and we don't trust you to do it another
way."  Not necessarily me personally, but I feel that myself or other
people who write good code are being forced to conform to the common
denominator by this argument.

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

This is my main point.  I think programs that make use of elegant
exception handling are punished by making sure all logged exceptions
require a pertinent explanation, when that explanation already exists
in either/both the exception's description and the stack trace.
Again, the lowest common denominator problem.  If users don't write
good code in the first place, SLF4J's interface isn't going to change
that ;).

>
>> 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 took the joke humorously, and was turning it on itself considering I
don't think it's a good thing.

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

That's a shame.  Although I know it's a pain for those who implement
library interfaces to have to update to a new interface, it does
happen as time goes on (for example, I've had to upgrade many projects
from log4j to slf4j).  This is an instance that wouldn't require
_that_ much pain, as I can only imagine how quickly and easily this
particular new interface method requirement would be met... copy the
same methods, but just don't log a message string, only the stack
trace.

Anyways, it's something to keep in mind for next time, I figured since
TRACE was reimplemented it wouldn't hurt to throw my two cents in
there.  As many readers can attest to, code style is an art of form
and functionality, and being forced to conform to (in the artist's
opinion) an inferior style can be repugnant.

-Matt