Hi Glen,
When I first read your message, for a second I was worried that
SLF4J's current API would allow inadvertent hiding exceptions.
However, your example
logger.debug("Here is the xml ..."+ largeXmlDocument , exception );
is *not* concerned with hidden exceptions but with performance. To be
honest, I must say that I am not totally convinced. Exceptions are by
definition exceptional meaning that they do not occur frequently. If
they don't occur frequently, performance is not such a big
issue. Would you agree?
However, if for some reason the exception is thrown frequently, you'd
pay they cost of converting the "largeXmlDocument" to String even if
the log statement was disabled.
I find the following case more troublesome:
logger.debug("Here is the xml {}", largeXmlDocument, exception );
The exception would be swallowed by the current API. Now, imho that's
a timebomb waiting to happen.
Glen Marchesani wrote:
Thanks for your answer Ceki. Your response is very clear. I hadn't
realized that this should have been targeted at the SLF4J list thanks
for answering it anyway. If you want I can join the SLF4J mailing list
and ask it there.
I agree it is not a serious limitation. It is a subtle limitation. I
am an architect on a large project and we always have to choose the more
intuitive route with fewer subtle pitfalls since all developer's won't
be logging nuts and understand the very subtle differences between the
two examples.
Take this
logger.debug("Here is the xml for the service request\n {} ",
largeXmlDomDocument );
and turn it into this to add an exception
logger.debug("Here is the xml for the service request\n" +
largeXmlDomDocument , exception );
This could be a time bomb waiting to happen on a production system with
debug logging turned off. A very hard to trace performance hit since
the lines of code are so seemingly the same. Of the 16 people on our
team I would say only 2 developer's would actually be able to catch that
and cite it as a change that is a potential performance hit.
I completely understand the necessity of not making changes to a core
api lightly. What about having inferred throwables be a system property
(or some form of config setting)?
On 9/3/07, *Ceki Gulcu* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
Hi Glen,
Thanks for sharing your idea. I think it makes sense. As you
observer, the
current API cannot deal with parameterized logging in conjunction
with exceptions.
However, I do not think it's a serious limitation because:
1) when confronted with exceptions, the performance of evaluating
whether to log
or not is not that important (as you usually would want to log)
2) if for some odd reason you need the performance in case of
exceptions, you
can always write
if(logger.isErrorEnabled()) {
logger.error("User name ["+name+"] does not match", exception);
}
In summary, although the current API is completely coherent, it
meets most
needs. More importantly, since logback's core logging API derives
from SLF4J, we
cannnot change logback's behavior without also changing SLF4J which
I am not
keen to do. :-)
Does the above make sense?
Glen Marchesani wrote:
> I love the project and am glad to see the new features added to
logging
> in general.
>
> I am willing to write a patch for a feature but before I do I
want to
> make sure it is something you would be interested in.
>
> There is no way to get a stack trace when using paramterized logging.
> The patch I want to add is that if the last parameter is a Throwable
> then it gets passed to the fitlerAndLog() method as a thorable
(instead
> of throwable being null).
>
> To explain in code.
> log.debug( "Something happened parm1={} parm2={} parm3={}", 1, 2,
3, new
> Throwable() );
>
>
> This would not cause the Throwable to be logged. So here are my
questions
>
> - if I added the code to ch.qos.logback.classic.Logger is that
something
> you are interested in?
>
> - lacking that any recommendations on how to get this feature
built in.
>
>
> Looking forward to your comments and thanks for the great work on a
> great logging framework...
>
> regards,
> Glen
>
>
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> logback-dev mailing list
> [email protected] <mailto:[email protected]>
> http://qos.ch/mailman/listinfo/logback-dev
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework
for Java.
http://logback.qos.ch
_______________________________________________
logback-dev mailing list
[email protected] <mailto:[email protected]>
http://qos.ch/mailman/listinfo/logback-dev
------------------------------------------------------------------------
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
