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 [EMAIL PROTECTED] _______________________________________________ user mailing list [email protected] http://www.slf4j.org/mailman/listinfo/user
