[logback-dev] implied Throwables
Glen Marchesani
glen at model3.net
Tue Sep 11 19:58:11 CEST 2007
Thanks Ceki..
I agree my argument isn't great. I am trying to get you to see the light
that implied throwables is a feature that you want to implement.
Without it the projects I work on will have to stick with out internal
logging api.
The point I was making wasn't performance but code migration. Often the
people who maintain the code are not as well versed as the people
who created it.
The point I was making with
logger.debug("Here is the xml {}", largeXmlDocument, exception );
Was that with implied exceptions that would be the equivalent of
if ( logger.isDebugEnabled() ) {
logger.debug("Here is the xml " + largeXmlDocument, exception );
}
I agree given the current api's limitations that it is a time bomb and why I
am asking for impied exception feature.
We have a large number of developers that will undoubtedly think that slf4j
is like our existing internal api and make the mistake we both agree is a
mistake...
On 9/6/07, Ceki Gulcu <ceki at qos.ch> wrote:
>
> 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
> _______________________________________________
> logback-dev mailing list
> logback-dev at qos.ch
> http://qos.ch/mailman/listinfo/logback-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://qos.ch/pipermail/logback-dev/attachments/20070911/d4c32cf3/attachment.htm
More information about the logback-dev
mailing list