[logback-dev] implied Throwables

[Glen Marchesani]

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> 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
> > 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/20070904/b95a8d97/attachment.htm