[logback-dev] implied Throwables

[Ceki Gulcu]

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* <listid at qos.ch <mailto:listid at qos.ch>> 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
>      > logback-dev at qos.ch <mailto:logback-dev at qos.ch>
>      > 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
>     logback-dev at qos.ch <mailto:logback-dev at qos.ch>
>     http://qos.ch/mailman/listinfo/logback-dev
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> logback-dev mailing list
> logback-dev at qos.ch
> 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