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