<div><br>Thanks for your answer Ceki.&nbsp; Your response is very clear.&nbsp; I hadn&#39;t realized that this should have been targeted at the SLF4J list thanks for answering it anyway.&nbsp; If you want I can join the SLF4J mailing list and ask it there.&nbsp; 
<br><br>I agree it is not a serious limitation.&nbsp; It is a subtle limitation.&nbsp; 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&#39;s won&#39;t be logging nuts and understand the very subtle differences between the two examples.&nbsp; 
<br><br>Take this<br><br>logger.debug(&quot;Here is the xml for the service request\n {} &quot;, largeXmlDomDocument );<br><br><br>and turn it into this to add an exception<br><br>logger.debug(&quot;Here is the xml for the service request\n&quot; + largeXmlDomDocument , exception );
<br><br>This could be a time bomb waiting to happen on a production system with debug logging turned off.&nbsp; A very hard to trace performance hit since the lines of code are so seemingly the same.&nbsp; Of the 16 people on our team I would say only 2 developer&#39;s would actually be able to catch that 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 api lightly.&nbsp; What about having inferred throwables be a system property (or some form of config setting)?<br><br><br><br>&nbsp;</div>
<div><span class="gmail_quote">On 9/3/07, <b class="gmail_sendername">Ceki Gulcu</b> &lt;<a href="mailto:listid@qos.ch" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">listid@qos.ch</a>&gt; wrote:</span>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">Hi Glen,<br><br>Thanks for sharing your idea. I think it makes sense. As you observer, the<br>
current API cannot deal with parameterized logging in conjunction with exceptions.
<br><br>However, I do not think it&#39;s a serious limitation because:<br><br>1) when confronted with exceptions, the performance of evaluating 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 exceptions, you<br>can always write<br><br>if(logger.isErrorEnabled()) {<br>&nbsp;&nbsp;logger.error(&quot;User name [&quot;+name+&quot;] does not match&quot;, exception);
<br>}<br><br>In summary, although the current API is completely coherent, it meets most<br>needs. More importantly, since logback&#39;s core logging API derives from SLF4J, we<br>cannnot change logback&#39;s behavior without also changing SLF4J which I am not
<br>keen to do. :-)<br><br>Does the above make sense?<br><br><br><br>Glen Marchesani wrote:<br>&gt; I love the project and am glad to see the new features added to logging<br>&gt; in general.<br>&gt;<br>&gt; I am willing to write a patch for a feature but before I do I want to
<br>&gt; make sure it is something you would be interested in.<br>&gt;<br>&gt; There is no way to get a stack trace when using paramterized logging.<br>&gt; The patch I want to add is that if the last parameter is a Throwable
<br>&gt; then it gets passed to the fitlerAndLog() method as a thorable (instead<br>&gt; of throwable being null).<br>&gt;<br>&gt; To explain in code.<br>&gt; log.debug( &quot;Something happened parm1={} parm2={} parm3={}&quot;, 1, 2, 3, new
<br>&gt; Throwable() );<br>&gt;<br>&gt;<br>&gt; This would not cause the Throwable to be logged.&nbsp;&nbsp;So here are my questions<br>&gt;<br>&gt; - if I added the code to ch.qos.logback.classic.Logger is that something<br>&gt; you are interested in?
<br>&gt;<br>&gt; - lacking that any recommendations on how to get this feature built in.<br>&gt;<br>&gt;<br>&gt; Looking forward to your comments and thanks for the great work on a<br>&gt; great logging framework...<br>&gt;
<br>&gt; regards,<br>&gt; Glen<br>&gt;<br>&gt;<br>&gt;<br>&gt;<br>&gt; ------------------------------------------------------------------------<br>&gt;<br>&gt; _______________________________________________<br>&gt; logback-dev mailing list
<br>&gt; <a href="mailto:logback-dev@qos.ch" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">logback-dev@qos.ch</a><br>&gt; <a href="http://qos.ch/mailman/listinfo/logback-dev" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
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" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://logback.qos.ch</a><br>_______________________________________________<br>logback-dev mailing list<br><a href="mailto:logback-dev@qos.ch" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
logback-dev@qos.ch</a><br><a href="http://qos.ch/mailman/listinfo/logback-dev" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://qos.ch/mailman/listinfo/logback-dev</a><br></blockquote></div><br>