http://bugzilla.slf4j.org/show_bug.cgi?id=70
--- Comment #11 from Joern Huxhorn <[EMAIL PROTECTED]> 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. _______________________________________________ dev mailing list [email protected] http://www.slf4j.org/mailman/listinfo/dev
