[slf4j-dev] [Bug 31] Varargs for Logger methods

[bugzilla-daemon at pixie.qos.ch]

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





--- Comment #53 from Joern Huxhorn <joern at huxhorn.de>  2009-11-10 23:32:30 ---
Concerning the order of Throwable and parameters, I can only state that
everyone that made the mistake of putting both parameters and Throwable into a
logging method, expecting the Throwable to be used as the Throwable of the
logging event, put the Throwable after the parameters.

I really mean everyone and I'm talking about >5 people that made the mistake. A
guy teaching at the University of Darmstadt (at that time) told me that his
students expected exactly that behavior, too.

Because of that I'd seriously opt for what I'd call "empirical common sense" ;)
Beyond that, the rationale would be that the parameters would be next to the
message pattern that they correspond to, followed by a Throwable as it's the
case if there are no parameters at all.

I'd exchange supporting the common mistake in exchange for a bit of type-safety
that's not *really* necessary.

I think that the following is counter-intuitive:
("Pattern {} {}", new Throwable(), "Param1", "Param2")
This would be less counter-intuitive but not "compatible" to the current
("message", new Throwable()) idiom:
(new Throwable(), "Pattern {} {}", "Param1", "Param2")

Additionally, having less methods is indeed a plus in my books.
Adding an explicit Throwable would multiply the 2 log methods per level to 4
methods.
Instead, I'd suggest to properly document the "last unused parameter is used as
Throwable" behavior properly.

I'd probably even go so far and document e.g. info(..) simply as a convenient
shortcut for log(Level.INFO,..), putting the vast amount of documentation,
including that of the special Throwable behavior, only into that two log(..)
methods, making extensive use of @see.


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