<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Verdana">I'm not sure if this is what you're talking about
but here's what I use for logging exceptions:<br>
<br>
<a class="moz-txt-link-freetext" href="http://commons.apache.org/lang/api-release/org/apache/commons/lang/exception/ExceptionUtils.html#getFullStackTrace(java.lang.Throwable)">http://commons.apache.org/lang/api-release/org/apache/commons/lang/exception/ExceptionUtils.html#getFullStackTrace(java.lang.Throwable)</a></font><br>
<br>
For example:<br>
<br>
<tt> try {<br>
results =
directorySearch.getByGivenNameSurname(searchCriteria);<br>
}<br>
catch (final LimitExceededException e) {<br>
log.error("limit exceeded exception: {}",
ExceptionUtils.getStackTrace(e));<br>
}<br>
</tt><br>
<br>
Matt Quigley wrote:
<blockquote
cite="mid:212a34950807171008j1582efe8r4a8ecea1f33fe389@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">Matt Quigley wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-freetext" href="http://www.slf4j.org/faq.html#exception_message">http://www.slf4j.org/faq.html#exception_message</a>. However, what is
given is a series of arguments telling me I don't know what I'm doing.
</pre>
</blockquote>
<pre wrap="">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"?
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">OK.
</pre>
<blockquote type="cite">
<pre wrap="">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);
}
</pre>
</blockquote>
<pre wrap="">Yes.
</pre>
</blockquote>
<pre wrap=""><!---->
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 ;).
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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)".
</pre>
</blockquote>
<pre wrap=""><!---->
I took the joke humorously, and was turning it on itself considering I
don't think it's a good thing.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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!
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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
_______________________________________________
user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:user@slf4j.org">user@slf4j.org</a>
<a class="moz-txt-link-freetext" href="http://www.slf4j.org/mailman/listinfo/user">http://www.slf4j.org/mailman/listinfo/user</a>
</pre>
</blockquote>
</body>
</html>