You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Rich Midwinter <ri...@gmail.com> on 2012/03/14 20:09:16 UTC
Lack of Category.error(Throwable t)
Hi
I note that the following methods exist:
*error*(Object <http://java.sun.com/j2se/1.3/docs/api/java/lang/Object.html?is-external=true>
message)
*error*(Object <http://java.sun.com/j2se/1.3/docs/api/java/lang/Object.html?is-external=true>
message, Throwable
<http://java.sun.com/j2se/1.3/docs/api/java/lang/Throwable.html?is-external=true>
t)
But this one does not:
*error*(Throwable
<http://java.sun.com/j2se/1.3/docs/api/java/lang/Throwable.html?is-external=true>
t)
Although it's absence is implied by the following JavaDoc on the first
method I referred to:
*WARNING* Note that passing a Throwable
<http://java.sun.com/j2se/1.3/docs/api/java/lang/Throwable.html?is-external=true>
to this method will print the name of the Throwable but no stack
trace. To print a stack trace use the error(Object, Throwable)
<http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Category.html#error(java.lang.Object,%20java.lang.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
Re: Lack of Category.error(Throwable t)
Posted by Jacob Kjome <ho...@visi.com>.
I'm not sure this is worth doing? One issue I can think of breaking
compatibility with the SLF4J API (and possibly commons-logging). I realize
it's not the Apache Logging Project's responsibility to maintain compatibility
with SLF4J, but I'm not sure it's worth doing at this late juncture for
Log4j-1.2.x with a future move to Log4j-2.0.
Note the main argument for this change...
>> > 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.
...which I think is one of the reasons that, for SLF4J, Ceki chose to use
log(String, Throwable) rather than log(Object, Throwable), which wouldn't
suffer from being "overlooked" and "[losing] a stack trace". This looks to
have been a wise decision on Ceki's part.
Jake
On Thu, 15 Mar 2012 16:26:47 +0100
Christian Grobmeier <gr...@gmail.com> wrote:
> On Thu, Mar 15, 2012 at 4:25 PM, Gary Gregory <gg...@apache.org> wrote:
>>>
>>> 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
>>
>>
>> As long as I can do a couple of search and replaces, BC is not that
>> important to me in this case because the API is not big, it's a "nice to
>> have".
>
> This is certainly a strong argument... along with the version number
> change it would be possible. And how many methods might be removed? I
> think they are only less
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Lack of Category.error(Throwable t)
Posted by Christian Grobmeier <gr...@gmail.com>.
On Thu, Mar 15, 2012 at 4:25 PM, Gary Gregory <gg...@apache.org> wrote:
>>
>> 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
>
>
> As long as I can do a couple of search and replaces, BC is not that
> important to me in this case because the API is not big, it's a "nice to
> have".
This is certainly a strong argument... along with the version number
change it would be possible. And how many methods might be removed? I
think they are only less
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Lack of Category.error(Throwable t)
Posted by Gary Gregory <gg...@apache.org>.
On Thu, Mar 15, 2012 at 11:17 AM, Christian Grobmeier
<gr...@gmail.com>wrote:
> On Thu, Mar 15, 2012 at 4:07 PM, Gary Gregory <gg...@apache.org> wrote:
> > On Thu, Mar 15, 2012 at 10:55 AM, Christian Grobmeier <
> grobmeier@gmail.com>
> > 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
>
As long as I can do a couple of search and replaces, BC is not that
important to me in this case because the API is not big, it's a "nice to
have".
Gary
>
>
> >
> > Gary
> >
> >>
> >>
> >> Cheers!
> >> Christian
> >>
> >> On Wed, Mar 14, 2012 at 8:09 PM, Rich Midwinter
> >> <ri...@gmail.com> 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: log4j-dev-unsubscribe@logging.apache.org
> >> For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >>
> >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > 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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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://twitter.com/GaryGregory>
Re: Lack of Category.error(Throwable t)
Posted by Scott Deboy <sc...@gmail.com>.
I don't think you can really do this because of ambiguity.
Scott
On Mar 15, 2012, at 11:17 AM, Christian Grobmeier
<gr...@gmail.com> wrote:
> On Thu, Mar 15, 2012 at 4:07 PM, Gary Gregory <gg...@apache.org>
> wrote:
>> On Thu, Mar 15, 2012 at 10:55 AM, Christian Grobmeier <grobmeier@gmail.com
>> >
>> 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
>>> <ri...@gmail.com> 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: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> 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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Lack of Category.error(Throwable t)
Posted by Christian Grobmeier <gr...@gmail.com>.
On Thu, Mar 15, 2012 at 4:07 PM, Gary Gregory <gg...@apache.org> wrote:
> On Thu, Mar 15, 2012 at 10:55 AM, Christian Grobmeier <gr...@gmail.com>
> 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
>> <ri...@gmail.com> 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: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Lack of Category.error(Throwable t)
Posted by Gary Gregory <gg...@apache.org>.
On Thu, Mar 15, 2012 at 10:55 AM, Christian Grobmeier
<gr...@gmail.com>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? :)
Gary
>
> Cheers!
> Christian
>
> On Wed, Mar 14, 2012 at 8:09 PM, Rich Midwinter
> <ri...@gmail.com> 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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
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://twitter.com/GaryGregory>
Re: Lack of Category.error(Throwable t)
Posted by Christian Grobmeier <gr...@gmail.com>.
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
Cheers!
Christian
On Wed, Mar 14, 2012 at 8:09 PM, Rich Midwinter
<ri...@gmail.com> 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org