http://bugzilla.slf4j.org/show_bug.cgi?id=31 --- Comment #77 from Thorbjørn Ravn Andersen <thorbjoern@gmail.com> 2010-02-12 21:55:08 --- (In reply to comment #53)
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 think that your approach with having the varargs logger in a completely separate package is the right solution. I also think that the methods in the interface should be as simple as possible while still conveying meaning. In other words the mandatory formating string must be explicitly defined, but the exception cannot as it breaks the varargs convention (to my understanding). I'd vote for a new Logger interface in a separate package (shipped separately from slf4j-api too) providing only log.error(String, Object...) log.warn(String, Object...) log.info(String, Object...) log.debug(String, Object...) which then invokes the appropriate methods in the current slf4j API (unless Logback implements these too natively). Simply looking at the last element to see if it is a Throwable or not, should be enough? (This will also catch the oops-I-invoked-the-wrong-method). Otherwise log.error and log.errorException(String, Exception Object...) might be a good long term solution. My only concern is that it breaks the "log-where-I-came-from" mechanisms. This is less important to me. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.