I don't think you can really do this because of ambiguity.
Scott
On Mar 15, 2012, at 11:17 AM, Christian Grobmeier
<[email protected]> wrote:
On Thu, Mar 15, 2012 at 4:07 PM, Gary Gregory <[email protected]>
wrote:
On Thu, Mar 15, 2012 at 10:55 AM, Christian Grobmeier <[email protected]
>
wrote:
If I understand you right, your suggestion is to add:
error(Throwable t)
I don't see a reason why this cannot happen...
We just should not remove methods to keep bc, but adding should
not be a
problem
For 1.4? :)
har :-))
I am not really opposed - but we must not forget log4j 2.0 on which we
should focus.
Question: how important is 100% bc for 1.2.x line? My assumption is:
very much... but well, as mentioned, I am not really opposed - just
careful
Gary
Cheers!
Christian
On Wed, Mar 14, 2012 at 8:09 PM, Rich Midwinter
<[email protected]> wrote:
Hi
I note that the following methods exist:
error(Object message)
error(Object message, Throwable t)
But this one does not:
error(Throwable t)
Although it's absence is implied by the following JavaDoc on the
first
method I referred to:
WARNING Note that passing a Throwable to this method will print
the name
of
the Throwable but no stack trace. To print a stack trace use
the error(Object, Throwable) form instead.
Is there a reason I've overlooked to avoid adding a method that
just
takes a
throwable? It's quite frustrating to find out in production that
someone's
overlooked this and we've lost a stack trace. The fix often just
passes
in
t.getMessage() anyway.
Thanks
Rich
--
http://www.grobmeier.de
https://www.timeandbill.de
---
------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
E-Mail: [email protected] | [email protected]
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
