[slf4j-dev] Why no error(Throwable) on the Logger interface?

[Robert Elliot]

Hi Ceki,

I suppose I hadn't expected any of that would be an issue with a  
change that (from SLF4J API's perspective) would be solely adding new  
method signatures to the Logger interface whilst altering none of the  
existing ones; I think it should be fully backwards compatible with  
clients compiled against previous versions of SLF4J from a binary  
perspective.  I see you did precisely that, adding the trace level in  
version 1.4.  A quick test suggests that an app using a library  
compiled against 1.5.6 and another library compiled against 1.5.7- 
SNAPSHOT with the extra methods added to Logger by me responds quite  
happily so long as I have my 1.5.7-SNAPSHOT jar and a compatible  
implementation on the classpath.

Anyway, not exactly a big problem!  I was primarily asking out of  
curiousity as to whether it was a deliberate design decision or just a  
matter of not done originally and now not worth the pain of doing.

Rob

On 27 May 2009, at 14:19, Ceki Gulcu wrote:

> Hello Robert,
>
> As Jukka's mail indicates, the modification you suggest is not
> necessarily for the better. I personally tend to agree with
> Jukka. There are probably others who would be more inclined to agree
> with your position.  However, even in cases where we all agree on the
> merits of a change, e.g. varargs [1], given that SLF4J is used by a
> large number of components, we can't take the risk of making backward
> incompatible changes. Even small *internal* changes have had important
> repercussions in the past [2]. Changing major version numbers, would
> not be of any help. If your project, say A, depends on library B which
> uses SLF4J, and on library C which used SLF4J-2, assuming SLF4J and
> SLF4J-2 are incompatible, you'd be stuck and probably reduced to
> cursing SLF4J.
>
> [1] http://bugzilla.slf4j.org/show_bug.cgi?id=31
> [2] http://slf4j.org/faq.html#IllegalAccessError
> [3] http://slf4j.org/faq.html#version_checks
>
> Robert Elliot wrote:
>> Just curious about this - I often find myself catching an exception  
>> and not really having anything to say about it other than that I  
>> want to log the exception.  So I end up calling  
>> log.error(ex.getMessage(), ex) - which seems a bit redundant as  
>> I'll get the message out anyway.
>> I understand why you couldn't do it in log4j, because there was  
>> already an error(Object) and so you'd have confusion over whether  
>> they wanted to log the exception including stack trace or just the  
>> exception's toString.  But as that vagueness has been cleared up in  
>> SLF4J it would be quite clear which method you were calling -  
>> error(Throwable) or error(String).
>> Is it just too late to add it, since all SLF4J implementations  
>> would need to be altered to implement it?  Ceki does effectively  
>> control rather a lot of the SLF4J implementations (the JULI one,  
>> the Log4J one, logback and slf4j-simple).  If it were added (say in  
>> a theoretical SLF4J 2) then I presume that it would still be OK for  
>> the end user - a library compiled against SLF4J 1.x would still  
>> work alongside libraries compiled against SLF4J 2 and using an  
>> SLF4J 2 implementation.
>> Just a query.
>> Rob
>
> -- 
> Ceki Gülcü
> Logback: The reliable, generic, fast and flexible logging framework  
> for Java.
> http://logback.qos.ch
> _______________________________________________
> dev mailing list
> dev at slf4j.org
> http://www.slf4j.org/mailman/listinfo/dev