You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Jonathan Locke <jo...@gmail.com> on 2007/05/30 03:46:35 UTC
abbreviated stack traces
while i like shorter stack traces in some sense, i've run into a couple of
cases where the stack trace being shown by wicket cut out important
information. could we review the code in Strings.toString(Throwable) to
make sure we're really doing the right thing here? i'd rather have too much
stack trace information from wicket than lose a key piece of info at a
critical time. unless we can feel really sure we're not cutting out
important information, i think we ought to err on the safe side.
--
View this message in context: http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10866083
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: abbreviated stack traces
Posted by Martijn Dashorst <ma...@gmail.com>.
For the component use check I specifically removed any
non-wicket-markup stack elements, otherwise the stack trace contains
too much information. Though I'm not sure if you are referring to
that.
Martijn
On 5/31/07, Johan Compagner <jc...@gmail.com> wrote:
> Which part do you mis then?
> because the root isn't cut of:
> sb.append("Root cause:\n\n");
> outputThrowable(cause, sb, false); << false is don't stop at
> wicket servlet.
>
> all other causes do stop at the wicket servlet (but those are mostly just
> invocation target and so on)
>
> for all we just skip the: !(traceString.startsWith("sun.reflect.")
> so that we don't have all those reflection stacks in it that don't give you
> any information then you already had.
>
> johan
>
>
> On 5/30/07, Jonathan Locke <jo...@gmail.com> wrote:
> >
> >
> > while i like shorter stack traces in some sense, i've run into a couple of
> > cases where the stack trace being shown by wicket cut out important
> > information. could we review the code in Strings.toString(Throwable) to
> > make sure we're really doing the right thing here? i'd rather have too
> > much
> > stack trace information from wicket than lose a key piece of info at a
> > critical time. unless we can feel really sure we're not cutting out
> > important information, i think we ought to err on the safe side.
> >
> > --
> > View this message in context:
> > http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10866083
> > Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >
> >
>
--
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.6 contains a very important fix. Download Wicket now!
http://wicketframework.org
Re: abbreviated stack traces
Posted by Johan Compagner <jc...@gmail.com>.
still again. what do we mess up
i haven't seen an example yet i am very curious about that
because we do print once the Complete stacktrace and that is of the root
cause
The only thing we do different then then java itself is that we dont do
top exception
xxxx
top-1 exception
xxx
10 more..
top-2 exception
xxxx
20 more..
root cause
xxxx
30 more..
no we do only the complete root cause immediantly as the top one. Because
that is what you want to see.
On 6/21/07, Jonathan Locke <jo...@gmail.com> wrote:
>
>
>
> i just want to change the code so that Strings.toString(throwable) does
> not
> do this.
> we can move this stack trace trimming code into the exception page. that
> way we're
> 100% sure that it will never mess up.
>
> i think at least one of the truncated stack traces i've found was caused
> by
> multithreading
> in the log files, but i still feel very uneasy about anything that
> processes
> stack trace
> strings. i think only the exception page display code should do that if
> anything.
>
> maybe the exception display page should just hide all the extra details
> using a javascript
> triggered fold-out instead of trying to programmatically remove it? i
> would
> feel better if
> we simply weren't doing this trimming at all.
>
>
> Johan Compagner wrote:
> >
> > i still don't get it what then should be changed
> > We are printing the complete stack..
> > the root cause is completely printed. Only the exceptions around the
> root
> > cause is not completely printed. (those are stopped at the wicket
> > servlet/filter)
> >
> > johan
> >
> >
> > On 6/20/07, Jonathan Locke <jo...@gmail.com> wrote:
> >>
> >>
> >>
> >> do i need a vote to make this change at this point?
> >>
> >>
> >> Eelco Hillenius wrote:
> >> >
> >> >> It might be good to be more defensive here then (as I think the
> trace
> >> I
> >> >> got
> >> >> had lost the info in both places): We could turn
> >> >> Strings.toString(Throwable)
> >> >> back into a simple version that always gives you the entire stack
> >> trace
> >> >> (I
> >> >> would really prefer that since this is supposed to be a generic
> >> utility).
> >> >> Then take the fancy version that's in the util package now and make
> a
> >> >> private implementation detail of the exception page(s). That way
> >> nobody
> >> >> can
> >> >> accidentally make the mistake of removing exception information from
> a
> >> >> log
> >> >> or the console.
> >> >
> >> > I agree.
> >> >
> >> > Eelco
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a11219888
> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a11224009
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: abbreviated stack traces
Posted by Eelco Hillenius <ee...@gmail.com>.
> maybe the exception display page should just hide all the extra details
> using a javascript
> triggered fold-out instead of trying to programmatically remove it?
That would be nice.
Eelco
Re: abbreviated stack traces
Posted by Jonathan Locke <jo...@gmail.com>.
i just want to change the code so that Strings.toString(throwable) does not
do this.
we can move this stack trace trimming code into the exception page. that
way we're
100% sure that it will never mess up.
i think at least one of the truncated stack traces i've found was caused by
multithreading
in the log files, but i still feel very uneasy about anything that processes
stack trace
strings. i think only the exception page display code should do that if
anything.
maybe the exception display page should just hide all the extra details
using a javascript
triggered fold-out instead of trying to programmatically remove it? i would
feel better if
we simply weren't doing this trimming at all.
Johan Compagner wrote:
>
> i still don't get it what then should be changed
> We are printing the complete stack..
> the root cause is completely printed. Only the exceptions around the root
> cause is not completely printed. (those are stopped at the wicket
> servlet/filter)
>
> johan
>
>
> On 6/20/07, Jonathan Locke <jo...@gmail.com> wrote:
>>
>>
>>
>> do i need a vote to make this change at this point?
>>
>>
>> Eelco Hillenius wrote:
>> >
>> >> It might be good to be more defensive here then (as I think the trace
>> I
>> >> got
>> >> had lost the info in both places): We could turn
>> >> Strings.toString(Throwable)
>> >> back into a simple version that always gives you the entire stack
>> trace
>> >> (I
>> >> would really prefer that since this is supposed to be a generic
>> utility).
>> >> Then take the fancy version that's in the util package now and make a
>> >> private implementation detail of the exception page(s). That way
>> nobody
>> >> can
>> >> accidentally make the mistake of removing exception information from a
>> >> log
>> >> or the console.
>> >
>> > I agree.
>> >
>> > Eelco
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a11219888
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a11224009
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: abbreviated stack traces
Posted by Johan Compagner <jc...@gmail.com>.
i still don't get it what then should be changed
We are printing the complete stack..
the root cause is completely printed. Only the exceptions around the root
cause is not completely printed. (those are stopped at the wicket
servlet/filter)
johan
On 6/20/07, Jonathan Locke <jo...@gmail.com> wrote:
>
>
>
> do i need a vote to make this change at this point?
>
>
> Eelco Hillenius wrote:
> >
> >> It might be good to be more defensive here then (as I think the trace I
> >> got
> >> had lost the info in both places): We could turn
> >> Strings.toString(Throwable)
> >> back into a simple version that always gives you the entire stack trace
> >> (I
> >> would really prefer that since this is supposed to be a generic
> utility).
> >> Then take the fancy version that's in the util package now and make a
> >> private implementation detail of the exception page(s). That way
> nobody
> >> can
> >> accidentally make the mistake of removing exception information from a
> >> log
> >> or the console.
> >
> > I agree.
> >
> > Eelco
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a11219888
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: abbreviated stack traces
Posted by Jonathan Locke <jo...@gmail.com>.
do i need a vote to make this change at this point?
Eelco Hillenius wrote:
>
>> It might be good to be more defensive here then (as I think the trace I
>> got
>> had lost the info in both places): We could turn
>> Strings.toString(Throwable)
>> back into a simple version that always gives you the entire stack trace
>> (I
>> would really prefer that since this is supposed to be a generic utility).
>> Then take the fancy version that's in the util package now and make a
>> private implementation detail of the exception page(s). That way nobody
>> can
>> accidentally make the mistake of removing exception information from a
>> log
>> or the console.
>
> I agree.
>
> Eelco
>
>
--
View this message in context: http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a11219888
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: abbreviated stack traces
Posted by Eelco Hillenius <ee...@gmail.com>.
> It might be good to be more defensive here then (as I think the trace I got
> had lost the info in both places): We could turn Strings.toString(Throwable)
> back into a simple version that always gives you the entire stack trace (I
> would really prefer that since this is supposed to be a generic utility).
> Then take the fancy version that's in the util package now and make a
> private implementation detail of the exception page(s). That way nobody can
> accidentally make the mistake of removing exception information from a log
> or the console.
I agree.
Eelco
Re: abbreviated stack traces
Posted by Al Maw <wi...@almaw.com>.
Johan Compagner wrote:
> why would we have a Strings.toString(Throwable) that gives you everything?
> then the normal thing (toString of the exception) just works just as fine.
Exception#toString() doesn't give you much, actually.
It only gives you the message in that exception, no nested exception, no
stack trace, etc.
Al
--
Alastair Maw
Wicket-biased blog at http://herebebeasties.com
Re: abbreviated stack traces
Posted by Jonathan Locke <jo...@gmail.com>.
that's the whole point. if you want to add a string representation of a
stack trace to another string, you need this method. Throwable.toString()
does not work. you need to say "my exception = " +
Strings.toString(exception).
Johan Compagner wrote:
>
> ahh sorry i meant printStackTrace() (and toString)
>
> johan
>
>
> On 5/31/07, Jonathan Locke <jo...@gmail.com> wrote:
>>
>>
>>
>> that was a couple days ago. i will let you know if i repro.
>>
>> the normal toString() does not give you the complete exception. it just
>> gives
>> you just the message string (see Throwable.java):
>>
>> public String toString() {
>> String s = getClass().getName();
>> String message = getLocalizedMessage();
>> return (message != null) ? (s + ": " + message) : s;
>> }
>>
>> this was the original point of Strings.toString(Throwable)... to give you
>> the complete trace for an exception object.
>>
>>
>> Johan Compagner wrote:
>> >
>> > why would we have a Strings.toString(Throwable) that gives you
>> everything?
>> > then the normal thing (toString of the exception) just works just as
>> fine.
>> >
>> > johan
>> >
>> >
>> >
>> > On 5/31/07, Jonathan Locke <jo...@gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> It might be good to be more defensive here then (as I think the trace
>> I
>> >> got
>> >> had lost the info in both places): We could turn Strings.toString
>> >> (Throwable)
>> >> back into a simple version that always gives you the entire stack
>> trace
>> >> (I
>> >> would really prefer that since this is supposed to be a generic
>> utility).
>> >> Then take the fancy version that's in the util package now and make a
>> >> private implementation detail of the exception page(s). That way
>> nobody
>> >> can
>> >> accidentally make the mistake of removing exception information from a
>> >> log
>> >> or the console.
>> >>
>> >>
>> >> Johan Compagner wrote:
>> >> >
>> >> > the full thing should go into the log
>> >> > i can't believe that that strings.toString(throwable) is used for
>> >> logging
>> >> > thats pure for our page itself i think
>> >> >
>> >> > johan
>> >> >
>> >> >
>> >> > On 5/31/07, Jonathan Locke <jo...@gmail.com> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> This happened a few days ago, so I don't recall for sure, but I
>> >> believe
>> >> I
>> >> >> was missing information from the cause exception which would have
>> >> helped
>> >> >> me
>> >> >> diagnose my problem. There are two things I can think of that
>> might
>> >> >> help.
>> >> >> We could: 1) take some extra precautions to only remove specific
>> stuff
>> >> we
>> >> >> know doesn't matter and 2) always print full stack traces to the
>> >> >> log/console
>> >> >> but put the abbreviated exception in the error page.
>> >> >>
>> >> >>
>> >> >> Johan Compagner wrote:
>> >> >> >
>> >> >> > Which part do you mis then?
>> >> >> > because the root isn't cut of:
>> >> >> > sb.append("Root cause:\n\n");
>> >> >> > outputThrowable(cause, sb, false); << false is don't
>> >> stop
>> >> >> at
>> >> >> > wicket servlet.
>> >> >> >
>> >> >> > all other causes do stop at the wicket servlet (but those are
>> mostly
>> >> >> just
>> >> >> > invocation target and so on)
>> >> >> >
>> >> >> > for all we just skip the:
>> !(traceString.startsWith("sun.reflect.")
>> >> >> > so that we don't have all those reflection stacks in it that
>> don't
>> >> give
>> >> >> > you
>> >> >> > any information then you already had.
>> >> >> >
>> >> >> > johan
>> >> >> >
>> >> >> >
>> >> >> > On 5/30/07, Jonathan Locke <jo...@gmail.com> wrote:
>> >> >> >>
>> >> >> >>
>> >> >> >> while i like shorter stack traces in some sense, i've run into a
>> >> >> couple
>> >> >> >> of
>> >> >> >> cases where the stack trace being shown by wicket cut out
>> important
>> >> >> >> information. could we review the code in Strings.toString
>> >> (Throwable)
>> >> >> to
>> >> >> >> make sure we're really doing the right thing here? i'd rather
>> have
>> >> >> too
>> >> >> >> much
>> >> >> >> stack trace information from wicket than lose a key piece of
>> info
>> >> at
>> >> a
>> >> >> >> critical time. unless we can feel really sure we're not cutting
>> out
>> >> >> >> important information, i think we ought to err on the safe side.
>> >> >> >>
>> >> >> >> --
>> >> >> >> View this message in context:
>> >> >> >>
>> >> >>
>> >>
>> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10866083
>> >> >> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10895556
>> >> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10896903
>> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10899655
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10900623
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: abbreviated stack traces
Posted by Johan Compagner <jc...@gmail.com>.
ahh sorry i meant printStackTrace() (and toString)
johan
On 5/31/07, Jonathan Locke <jo...@gmail.com> wrote:
>
>
>
> that was a couple days ago. i will let you know if i repro.
>
> the normal toString() does not give you the complete exception. it just
> gives
> you just the message string (see Throwable.java):
>
> public String toString() {
> String s = getClass().getName();
> String message = getLocalizedMessage();
> return (message != null) ? (s + ": " + message) : s;
> }
>
> this was the original point of Strings.toString(Throwable)... to give you
> the complete trace for an exception object.
>
>
> Johan Compagner wrote:
> >
> > why would we have a Strings.toString(Throwable) that gives you
> everything?
> > then the normal thing (toString of the exception) just works just as
> fine.
> >
> > johan
> >
> >
> >
> > On 5/31/07, Jonathan Locke <jo...@gmail.com> wrote:
> >>
> >>
> >>
> >> It might be good to be more defensive here then (as I think the trace I
> >> got
> >> had lost the info in both places): We could turn Strings.toString
> >> (Throwable)
> >> back into a simple version that always gives you the entire stack trace
> >> (I
> >> would really prefer that since this is supposed to be a generic
> utility).
> >> Then take the fancy version that's in the util package now and make a
> >> private implementation detail of the exception page(s). That way
> nobody
> >> can
> >> accidentally make the mistake of removing exception information from a
> >> log
> >> or the console.
> >>
> >>
> >> Johan Compagner wrote:
> >> >
> >> > the full thing should go into the log
> >> > i can't believe that that strings.toString(throwable) is used for
> >> logging
> >> > thats pure for our page itself i think
> >> >
> >> > johan
> >> >
> >> >
> >> > On 5/31/07, Jonathan Locke <jo...@gmail.com> wrote:
> >> >>
> >> >>
> >> >>
> >> >> This happened a few days ago, so I don't recall for sure, but I
> >> believe
> >> I
> >> >> was missing information from the cause exception which would have
> >> helped
> >> >> me
> >> >> diagnose my problem. There are two things I can think of that might
> >> >> help.
> >> >> We could: 1) take some extra precautions to only remove specific
> stuff
> >> we
> >> >> know doesn't matter and 2) always print full stack traces to the
> >> >> log/console
> >> >> but put the abbreviated exception in the error page.
> >> >>
> >> >>
> >> >> Johan Compagner wrote:
> >> >> >
> >> >> > Which part do you mis then?
> >> >> > because the root isn't cut of:
> >> >> > sb.append("Root cause:\n\n");
> >> >> > outputThrowable(cause, sb, false); << false is don't
> >> stop
> >> >> at
> >> >> > wicket servlet.
> >> >> >
> >> >> > all other causes do stop at the wicket servlet (but those are
> mostly
> >> >> just
> >> >> > invocation target and so on)
> >> >> >
> >> >> > for all we just skip the: !(traceString.startsWith("sun.reflect.")
> >> >> > so that we don't have all those reflection stacks in it that don't
> >> give
> >> >> > you
> >> >> > any information then you already had.
> >> >> >
> >> >> > johan
> >> >> >
> >> >> >
> >> >> > On 5/30/07, Jonathan Locke <jo...@gmail.com> wrote:
> >> >> >>
> >> >> >>
> >> >> >> while i like shorter stack traces in some sense, i've run into a
> >> >> couple
> >> >> >> of
> >> >> >> cases where the stack trace being shown by wicket cut out
> important
> >> >> >> information. could we review the code in Strings.toString
> >> (Throwable)
> >> >> to
> >> >> >> make sure we're really doing the right thing here? i'd rather
> have
> >> >> too
> >> >> >> much
> >> >> >> stack trace information from wicket than lose a key piece of info
> >> at
> >> a
> >> >> >> critical time. unless we can feel really sure we're not cutting
> out
> >> >> >> important information, i think we ought to err on the safe side.
> >> >> >>
> >> >> >> --
> >> >> >> View this message in context:
> >> >> >>
> >> >>
> >> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10866083
> >> >> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10895556
> >> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10896903
> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10899655
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: abbreviated stack traces
Posted by Jonathan Locke <jo...@gmail.com>.
that was a couple days ago. i will let you know if i repro.
the normal toString() does not give you the complete exception. it just
gives
you just the message string (see Throwable.java):
public String toString() {
String s = getClass().getName();
String message = getLocalizedMessage();
return (message != null) ? (s + ": " + message) : s;
}
this was the original point of Strings.toString(Throwable)... to give you
the complete trace for an exception object.
Johan Compagner wrote:
>
> why would we have a Strings.toString(Throwable) that gives you everything?
> then the normal thing (toString of the exception) just works just as fine.
>
> johan
>
>
>
> On 5/31/07, Jonathan Locke <jo...@gmail.com> wrote:
>>
>>
>>
>> It might be good to be more defensive here then (as I think the trace I
>> got
>> had lost the info in both places): We could turn Strings.toString
>> (Throwable)
>> back into a simple version that always gives you the entire stack trace
>> (I
>> would really prefer that since this is supposed to be a generic utility).
>> Then take the fancy version that's in the util package now and make a
>> private implementation detail of the exception page(s). That way nobody
>> can
>> accidentally make the mistake of removing exception information from a
>> log
>> or the console.
>>
>>
>> Johan Compagner wrote:
>> >
>> > the full thing should go into the log
>> > i can't believe that that strings.toString(throwable) is used for
>> logging
>> > thats pure for our page itself i think
>> >
>> > johan
>> >
>> >
>> > On 5/31/07, Jonathan Locke <jo...@gmail.com> wrote:
>> >>
>> >>
>> >>
>> >> This happened a few days ago, so I don't recall for sure, but I
>> believe
>> I
>> >> was missing information from the cause exception which would have
>> helped
>> >> me
>> >> diagnose my problem. There are two things I can think of that might
>> >> help.
>> >> We could: 1) take some extra precautions to only remove specific stuff
>> we
>> >> know doesn't matter and 2) always print full stack traces to the
>> >> log/console
>> >> but put the abbreviated exception in the error page.
>> >>
>> >>
>> >> Johan Compagner wrote:
>> >> >
>> >> > Which part do you mis then?
>> >> > because the root isn't cut of:
>> >> > sb.append("Root cause:\n\n");
>> >> > outputThrowable(cause, sb, false); << false is don't
>> stop
>> >> at
>> >> > wicket servlet.
>> >> >
>> >> > all other causes do stop at the wicket servlet (but those are mostly
>> >> just
>> >> > invocation target and so on)
>> >> >
>> >> > for all we just skip the: !(traceString.startsWith("sun.reflect.")
>> >> > so that we don't have all those reflection stacks in it that don't
>> give
>> >> > you
>> >> > any information then you already had.
>> >> >
>> >> > johan
>> >> >
>> >> >
>> >> > On 5/30/07, Jonathan Locke <jo...@gmail.com> wrote:
>> >> >>
>> >> >>
>> >> >> while i like shorter stack traces in some sense, i've run into a
>> >> couple
>> >> >> of
>> >> >> cases where the stack trace being shown by wicket cut out important
>> >> >> information. could we review the code in Strings.toString
>> (Throwable)
>> >> to
>> >> >> make sure we're really doing the right thing here? i'd rather have
>> >> too
>> >> >> much
>> >> >> stack trace information from wicket than lose a key piece of info
>> at
>> a
>> >> >> critical time. unless we can feel really sure we're not cutting out
>> >> >> important information, i think we ought to err on the safe side.
>> >> >>
>> >> >> --
>> >> >> View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10866083
>> >> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10895556
>> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10896903
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10899655
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: abbreviated stack traces
Posted by Johan Compagner <jc...@gmail.com>.
why would we have a Strings.toString(Throwable) that gives you everything?
then the normal thing (toString of the exception) just works just as fine.
johan
On 5/31/07, Jonathan Locke <jo...@gmail.com> wrote:
>
>
>
> It might be good to be more defensive here then (as I think the trace I
> got
> had lost the info in both places): We could turn Strings.toString
> (Throwable)
> back into a simple version that always gives you the entire stack trace (I
> would really prefer that since this is supposed to be a generic utility).
> Then take the fancy version that's in the util package now and make a
> private implementation detail of the exception page(s). That way nobody
> can
> accidentally make the mistake of removing exception information from a log
> or the console.
>
>
> Johan Compagner wrote:
> >
> > the full thing should go into the log
> > i can't believe that that strings.toString(throwable) is used for
> logging
> > thats pure for our page itself i think
> >
> > johan
> >
> >
> > On 5/31/07, Jonathan Locke <jo...@gmail.com> wrote:
> >>
> >>
> >>
> >> This happened a few days ago, so I don't recall for sure, but I believe
> I
> >> was missing information from the cause exception which would have
> helped
> >> me
> >> diagnose my problem. There are two things I can think of that might
> >> help.
> >> We could: 1) take some extra precautions to only remove specific stuff
> we
> >> know doesn't matter and 2) always print full stack traces to the
> >> log/console
> >> but put the abbreviated exception in the error page.
> >>
> >>
> >> Johan Compagner wrote:
> >> >
> >> > Which part do you mis then?
> >> > because the root isn't cut of:
> >> > sb.append("Root cause:\n\n");
> >> > outputThrowable(cause, sb, false); << false is don't stop
> >> at
> >> > wicket servlet.
> >> >
> >> > all other causes do stop at the wicket servlet (but those are mostly
> >> just
> >> > invocation target and so on)
> >> >
> >> > for all we just skip the: !(traceString.startsWith("sun.reflect.")
> >> > so that we don't have all those reflection stacks in it that don't
> give
> >> > you
> >> > any information then you already had.
> >> >
> >> > johan
> >> >
> >> >
> >> > On 5/30/07, Jonathan Locke <jo...@gmail.com> wrote:
> >> >>
> >> >>
> >> >> while i like shorter stack traces in some sense, i've run into a
> >> couple
> >> >> of
> >> >> cases where the stack trace being shown by wicket cut out important
> >> >> information. could we review the code in Strings.toString
> (Throwable)
> >> to
> >> >> make sure we're really doing the right thing here? i'd rather have
> >> too
> >> >> much
> >> >> stack trace information from wicket than lose a key piece of info at
> a
> >> >> critical time. unless we can feel really sure we're not cutting out
> >> >> important information, i think we ought to err on the safe side.
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10866083
> >> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10895556
> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10896903
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: abbreviated stack traces
Posted by Johan Compagner <jc...@gmail.com>.
i am still very curious what you think you missed
please give me an example
johan
On 5/31/07, Jonathan Locke <jo...@gmail.com> wrote:
>
>
>
> It might be good to be more defensive here then (as I think the trace I
> got
> had lost the info in both places): We could turn Strings.toString
> (Throwable)
> back into a simple version that always gives you the entire stack trace (I
> would really prefer that since this is supposed to be a generic utility).
> Then take the fancy version that's in the util package now and make a
> private implementation detail of the exception page(s). That way nobody
> can
> accidentally make the mistake of removing exception information from a log
> or the console.
>
>
> Johan Compagner wrote:
> >
> > the full thing should go into the log
> > i can't believe that that strings.toString(throwable) is used for
> logging
> > thats pure for our page itself i think
> >
> > johan
> >
> >
> > On 5/31/07, Jonathan Locke <jo...@gmail.com> wrote:
> >>
> >>
> >>
> >> This happened a few days ago, so I don't recall for sure, but I believe
> I
> >> was missing information from the cause exception which would have
> helped
> >> me
> >> diagnose my problem. There are two things I can think of that might
> >> help.
> >> We could: 1) take some extra precautions to only remove specific stuff
> we
> >> know doesn't matter and 2) always print full stack traces to the
> >> log/console
> >> but put the abbreviated exception in the error page.
> >>
> >>
> >> Johan Compagner wrote:
> >> >
> >> > Which part do you mis then?
> >> > because the root isn't cut of:
> >> > sb.append("Root cause:\n\n");
> >> > outputThrowable(cause, sb, false); << false is don't stop
> >> at
> >> > wicket servlet.
> >> >
> >> > all other causes do stop at the wicket servlet (but those are mostly
> >> just
> >> > invocation target and so on)
> >> >
> >> > for all we just skip the: !(traceString.startsWith("sun.reflect.")
> >> > so that we don't have all those reflection stacks in it that don't
> give
> >> > you
> >> > any information then you already had.
> >> >
> >> > johan
> >> >
> >> >
> >> > On 5/30/07, Jonathan Locke <jo...@gmail.com> wrote:
> >> >>
> >> >>
> >> >> while i like shorter stack traces in some sense, i've run into a
> >> couple
> >> >> of
> >> >> cases where the stack trace being shown by wicket cut out important
> >> >> information. could we review the code in Strings.toString
> (Throwable)
> >> to
> >> >> make sure we're really doing the right thing here? i'd rather have
> >> too
> >> >> much
> >> >> stack trace information from wicket than lose a key piece of info at
> a
> >> >> critical time. unless we can feel really sure we're not cutting out
> >> >> important information, i think we ought to err on the safe side.
> >> >>
> >> >> --
> >> >> View this message in context:
> >> >>
> >> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10866083
> >> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10895556
> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10896903
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: abbreviated stack traces
Posted by Jonathan Locke <jo...@gmail.com>.
It might be good to be more defensive here then (as I think the trace I got
had lost the info in both places): We could turn Strings.toString(Throwable)
back into a simple version that always gives you the entire stack trace (I
would really prefer that since this is supposed to be a generic utility).
Then take the fancy version that's in the util package now and make a
private implementation detail of the exception page(s). That way nobody can
accidentally make the mistake of removing exception information from a log
or the console.
Johan Compagner wrote:
>
> the full thing should go into the log
> i can't believe that that strings.toString(throwable) is used for logging
> thats pure for our page itself i think
>
> johan
>
>
> On 5/31/07, Jonathan Locke <jo...@gmail.com> wrote:
>>
>>
>>
>> This happened a few days ago, so I don't recall for sure, but I believe I
>> was missing information from the cause exception which would have helped
>> me
>> diagnose my problem. There are two things I can think of that might
>> help.
>> We could: 1) take some extra precautions to only remove specific stuff we
>> know doesn't matter and 2) always print full stack traces to the
>> log/console
>> but put the abbreviated exception in the error page.
>>
>>
>> Johan Compagner wrote:
>> >
>> > Which part do you mis then?
>> > because the root isn't cut of:
>> > sb.append("Root cause:\n\n");
>> > outputThrowable(cause, sb, false); << false is don't stop
>> at
>> > wicket servlet.
>> >
>> > all other causes do stop at the wicket servlet (but those are mostly
>> just
>> > invocation target and so on)
>> >
>> > for all we just skip the: !(traceString.startsWith("sun.reflect.")
>> > so that we don't have all those reflection stacks in it that don't give
>> > you
>> > any information then you already had.
>> >
>> > johan
>> >
>> >
>> > On 5/30/07, Jonathan Locke <jo...@gmail.com> wrote:
>> >>
>> >>
>> >> while i like shorter stack traces in some sense, i've run into a
>> couple
>> >> of
>> >> cases where the stack trace being shown by wicket cut out important
>> >> information. could we review the code in Strings.toString(Throwable)
>> to
>> >> make sure we're really doing the right thing here? i'd rather have
>> too
>> >> much
>> >> stack trace information from wicket than lose a key piece of info at a
>> >> critical time. unless we can feel really sure we're not cutting out
>> >> important information, i think we ought to err on the safe side.
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10866083
>> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>> >>
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10895556
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10896903
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: abbreviated stack traces
Posted by Johan Compagner <jc...@gmail.com>.
the full thing should go into the log
i can't believe that that strings.toString(throwable) is used for logging
thats pure for our page itself i think
johan
On 5/31/07, Jonathan Locke <jo...@gmail.com> wrote:
>
>
>
> This happened a few days ago, so I don't recall for sure, but I believe I
> was missing information from the cause exception which would have helped
> me
> diagnose my problem. There are two things I can think of that might help.
> We could: 1) take some extra precautions to only remove specific stuff we
> know doesn't matter and 2) always print full stack traces to the
> log/console
> but put the abbreviated exception in the error page.
>
>
> Johan Compagner wrote:
> >
> > Which part do you mis then?
> > because the root isn't cut of:
> > sb.append("Root cause:\n\n");
> > outputThrowable(cause, sb, false); << false is don't stop at
> > wicket servlet.
> >
> > all other causes do stop at the wicket servlet (but those are mostly
> just
> > invocation target and so on)
> >
> > for all we just skip the: !(traceString.startsWith("sun.reflect.")
> > so that we don't have all those reflection stacks in it that don't give
> > you
> > any information then you already had.
> >
> > johan
> >
> >
> > On 5/30/07, Jonathan Locke <jo...@gmail.com> wrote:
> >>
> >>
> >> while i like shorter stack traces in some sense, i've run into a couple
> >> of
> >> cases where the stack trace being shown by wicket cut out important
> >> information. could we review the code in Strings.toString(Throwable)
> to
> >> make sure we're really doing the right thing here? i'd rather have too
> >> much
> >> stack trace information from wicket than lose a key piece of info at a
> >> critical time. unless we can feel really sure we're not cutting out
> >> important information, i think we ought to err on the safe side.
> >>
> >> --
> >> View this message in context:
> >> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10866083
> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10895556
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: abbreviated stack traces
Posted by Jonathan Locke <jo...@gmail.com>.
This happened a few days ago, so I don't recall for sure, but I believe I
was missing information from the cause exception which would have helped me
diagnose my problem. There are two things I can think of that might help.
We could: 1) take some extra precautions to only remove specific stuff we
know doesn't matter and 2) always print full stack traces to the log/console
but put the abbreviated exception in the error page.
Johan Compagner wrote:
>
> Which part do you mis then?
> because the root isn't cut of:
> sb.append("Root cause:\n\n");
> outputThrowable(cause, sb, false); << false is don't stop at
> wicket servlet.
>
> all other causes do stop at the wicket servlet (but those are mostly just
> invocation target and so on)
>
> for all we just skip the: !(traceString.startsWith("sun.reflect.")
> so that we don't have all those reflection stacks in it that don't give
> you
> any information then you already had.
>
> johan
>
>
> On 5/30/07, Jonathan Locke <jo...@gmail.com> wrote:
>>
>>
>> while i like shorter stack traces in some sense, i've run into a couple
>> of
>> cases where the stack trace being shown by wicket cut out important
>> information. could we review the code in Strings.toString(Throwable) to
>> make sure we're really doing the right thing here? i'd rather have too
>> much
>> stack trace information from wicket than lose a key piece of info at a
>> critical time. unless we can feel really sure we're not cutting out
>> important information, i think we ought to err on the safe side.
>>
>> --
>> View this message in context:
>> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10866083
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10895556
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: abbreviated stack traces
Posted by Johan Compagner <jc...@gmail.com>.
Which part do you mis then?
because the root isn't cut of:
sb.append("Root cause:\n\n");
outputThrowable(cause, sb, false); << false is don't stop at
wicket servlet.
all other causes do stop at the wicket servlet (but those are mostly just
invocation target and so on)
for all we just skip the: !(traceString.startsWith("sun.reflect.")
so that we don't have all those reflection stacks in it that don't give you
any information then you already had.
johan
On 5/30/07, Jonathan Locke <jo...@gmail.com> wrote:
>
>
> while i like shorter stack traces in some sense, i've run into a couple of
> cases where the stack trace being shown by wicket cut out important
> information. could we review the code in Strings.toString(Throwable) to
> make sure we're really doing the right thing here? i'd rather have too
> much
> stack trace information from wicket than lose a key piece of info at a
> critical time. unless we can feel really sure we're not cutting out
> important information, i think we ought to err on the safe side.
>
> --
> View this message in context:
> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10866083
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: abbreviated stack traces
Posted by Nick Heudecker <nh...@gmail.com>.
I've had this problem as well. An exception thrown by Hibernate deep in the
stack wasn't displayed on the page.
Maybe the full stack could be displayed in a text area?
On 5/29/07, Jonathan Locke <jo...@gmail.com> wrote:
>
>
> while i like shorter stack traces in some sense, i've run into a couple of
> cases where the stack trace being shown by wicket cut out important
> information. could we review the code in Strings.toString(Throwable) to
> make sure we're really doing the right thing here? i'd rather have too
> much
> stack trace information from wicket than lose a key piece of info at a
> critical time. unless we can feel really sure we're not cutting out
> important information, i think we ought to err on the safe side.
>
> --
> View this message in context:
> http://www.nabble.com/abbreviated-stack-traces-tf3837742.html#a10866083
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
--
Nick Heudecker
Professional Wicket Training & Consulting
http://www.systemmobile.com
Eventful - Intelligent Event Management
http://www.eventfulhq.com