RE: [lang] Exception stack trace order

[Henri Yandell <ba...@generationjava.com>]

Looks pretty agreed upon that we want to reverse the stack trace.

Mohan seems to have done a fair amount of the work on this, though
probably more than the basic change discussed previously.

It seems we want three things:

1) Use JDK 1.4 Stack trace if in JVM 1.4.
2) Reverse order of the current stack trace.
3) Allow a static property to be set which redefines the order back to the
other way.


I'd like to add something to 3. If a system property
"jakarta.lang.reverseStackTrace" is set, then the static property
should be set to this. Where true would set it to the Lang 1.0 way, but
the default if it's not set is the jdk1.4 way. Just an idea :)

Anyway, Mohan:

Does your patch do more than 1)->3) above? It seems to but I'm trying to
avoid diving into ExceptionUtils right now. Are there important issues for
a Lang 2.0 release beyond the 3 points mentioned above? You mention the
stack trace looks garbled.

Thanks,

Hen


On Thu, 17 Apr 2003, Gary Gregory wrote:

> - Reversing the default stack trace order.
>
> I like the idea of matching the JDK stack trace order. Dealing with two
> stack trace formats is not a good thing IMO. When you are dealing with a
> large code base that uses 3rd party libraries, Jakarta and others, seing
> stacks this way and that way is not pleasant, not that seing one ever is!
>
> +1
>
> Gary
>
> -----Original Message-----
> From: scolebourne@btopenworld.com [mailto:scolebourne@btopenworld.com]
> Sent: Wednesday, April 16, 2003 4:52 AM
> To: commons-dev@jakarta.apache.org
> Subject: [lang] Exception stack trace order
>
> I support:
>
> - Reversing the default stack trace order.
>
> - Having a static flag set on ExceptionUtils/NestableDelegate to reverse
> order (back to current setup)
>
> - Using 1.4 getCause as appropriate
>
> - Having the ability to have truncated stack traces (but doesn't some of
> this exist in ExceptionUtils?)
>
> Stephen
>
> >  from:    Henri Yandell <ba...@generationjava.com>
> > Still trying to put this one to bed. Lots of interesting debate on the
> > bugzilla report for this:
> >
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=14357
> >
> > Steven Caswell, do you have a view on it? You're the most active name
> > frequently on the author javadoc for exception.* :)
> > Mohan has attached a set of fixes. One definite nice one is that it uses
> > the JDK 1.4 getCause method if available.
> >
> > Anyone else with a view? Alex seems to have  1'd my suggestion below of
> > changing, but also been against it on the bugzilla? ;)
> >
> > This is all that's really in the way of Lang 2.0 for us, so getting it
> > solved would be nice.
> >
> > Hen
> >
> > On Sun, 30 Mar 2003, Alex Chaffee / Purple Technology wrote:
> >
> > > On Sun, Mar 30, 2003 at 12:18:03AM -0500, Henri Yandell wrote:
> > > >
> > > > As well as the direction, it strikes me that there's another issue.
> > > > Whether to show the stack-trace for all exceptions in the list, or to
> show
> > > > a message for one of them. I think it almost calls for an
> ExceptionFormat
> > > > object :)
> > >
> > > You're kidding, but I honestly think that exceptions are an area where
> > > model-view separation could be productively applied.  Assert failures
> > > are another.  I'm imagining an exception that uses
> > > java.text.MessageFormat...
> > >
> > > > Anyway, our default behaviour should probably match the JDK. I seem to
> > > > recall we were in favour of this before, as we disliked the
> > > > static-solution suggested by the Bugzilla entry.
> > > >
> > > > All in favour?
> > >
> > >  1
> > >
> > >
> > > --
> > > Alex Chaffee                               mailto:alex@jguru.com
> > > Purple Technology - Code and Consulting    http://www.purpletech.com/
> > > jGuru - Java News and FAQs                 http://www.jguru.com/alex/
> > > Gamelan - the Original Java site           http://www.gamelan.com/
> > > Stinky - Art and Angst                     http://www.stinky.com/
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org