[slf4j-dev] [Bug 70] " logging a stack trace along with a parameterized string" solution proposal

[bugzilla-daemon at pixie.qos.ch]

http://bugzilla.slf4j.org/show_bug.cgi?id=70





--- Comment #11 from Joern Huxhorn <joern at huxhorn.de>  2008-09-14 19:53:09 ---
I can only argue that *every* person (I think about seven already) that talked
to me about this shortcoming of slf4j/logback was *always* assuming that the
exception was the last of the given arguments.

I even received some Lilith bug reports that guessed that it was a Lilith
problem that the exceptions wouldn't show up. That's one of the reasons why I
implemented a "fix" in my own appenders.

I'm also using the unformatted message in serialized events so my code is
essentially counting the placeholders to find out if a Throwable is supposed to
be used as a Throwable or just as a String for the given message.
Therefore it should be even faster during creation of the actual logging event.
(Please take a look at
http://lilith.svn.sourceforge.net/viewvc/lilith/trunk/lilith-data/logging/src/main/java/de/huxhorn/lilith/data/logging/MessageFormatter.java?view=markup
and
http://lilith.svn.sourceforge.net/viewvc/lilith/trunk/lilith-data/logging/src/main/java/de/huxhorn/lilith/data/logging/LoggingEvent.java?view=markup
if you are interested. The code doesn't reflect Cekis latest changes concerning
parameterized logging, yet)

I wouldn't consider this a hacky at all, either, since RTTI is available in
Java anyway - at a very moderate cost - and in other languages, e.g. printf in
C, something like that is also very common.
I don't remember the exact syntax so please don't hit me if I get it partially
wrong but essentially printf("%d", aTimestamp) in C does just assume that
aTimestamp is a date.

On the other hand, I don't think it would be very wise to add lots of new
method signatures to the Logger interface even though it's absolutely possible,
without any compatibility impact, to support the requested functionality in a
very transparent manner.

With "without any compatibility impact" I mean that the only change in behavior
will be that logging events with previously erroneously superfluous Throwables
will suddenly show them as most likely expected by the developer.

While compile-time type safety is something very nice, it shouldn't impact the
design of an API in a way that makes it *much* more complex.
What, exactly, would be the benefit of type safety at this specific location? 

What would be the way to actually use the throwable.toString() in a
parameterized logging message? Would you expect to manually use ""+throwable in
that case? Otherwise the method with Throwable as the first parameter would be
used.

I disagree that this would be a valid solution.


-- 
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.