You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <ba...@generationjava.com> on 2003/01/16 21:16:17 UTC

[lang] Bug #14357

I'd like to get this bug/issue dealt with.

http://issues.apache.org/bugzilla/show_bug.cgi?id=14357

NestableException [in Beta 1 apparantly] prints the stack trace with the
most relevant error at the bottom and not the top, as is common in most
app's.

Does anyone know if this was fixed and the bug not closed, or if it's
still an issue?

The bug-creator's suggestion is a system property. Obviously this has
serious issues and probably isn't acceptable. How else can it be solved?

Hen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [lang] Bug #14357 Stack trace order

Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Henri Yandell" <ba...@generationjava.com>
> On Sun, 19 Jan 2003, Stephen Colebourne wrote:
> > I would like to treat this as a bug, and just reverse the order to the
> > 'correct' one (compliant with JDK 1.4 and others).
>
> +1, though I expect the deprecation police to throw a tizzy.

We should release as 2.0 and list the changes. Doing this, we should go
through and check the NullPointerExceptions etc. thrown by our classes,
especially StringUtils. (I changed one today in replace()). If we handle
nulls better then we will increase the value of using [lang].


> > Otherwise, I think that a static setStackOrderHighestToLowest(boolean)
> > method is better than a system property.
>
> Acceptable [as is the property one] but I'd still want to reverse the
> default even if we did add some kind of way to modify the order.
> So it's more a question of: Should we keep the current way in anyway?

Not in my view ;-)

Stephen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [lang] Bug #14357 Stack trace order

Posted by Henri Yandell <ba...@generationjava.com>.

On Sun, 19 Jan 2003, Stephen Colebourne wrote:

> I would like to treat this as a bug, and just reverse the order to the
> 'correct' one (compliant with JDK 1.4 and others).

+1, though I expect the deprecation police to throw a tizzy.

> Otherwise, I think that a static setStackOrderHighestToLowest(boolean)
> method is better than a system property.

Acceptable [as is the property one] but I'd still want to reverse the
default even if we did add some kind of way to modify the order.
So it's more a question of: Should we keep the current way in anyway?

Hen


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [lang] Bug #14357 Stack trace order

Posted by Stephen Colebourne <sc...@btopenworld.com>.
I would like to treat this as a bug, and just reverse the order to the
'correct' one (compliant with JDK 1.4 and others).

Otherwise, I think that a static setStackOrderHighestToLowest(boolean)
method is better than a system property.

Stephen

----- Original Message -----
From: "Max Rydahl Andersen" <ma...@eos.dk>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Friday, January 17, 2003 2:21 PM
Subject: Re: [lang] Bug #14357


> I'm the bug-creator and if the usage of system property is unacceptable,
> then i'll
> suggest NestableException should be changed to conform better to how JDK
1.4
> prints
> exception - not just to be "complaint", but just to do the most reasonably
> expected thing...which is: Print the top-most exception first, and print
the
> lowest last.
>
> /max
>
> ----- Original Message -----
> From: "Henri Yandell" <ba...@generationjava.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Thursday, January 16, 2003 9:16 PM
> Subject: [lang] Bug #14357
>
>
> > I'd like to get this bug/issue dealt with.
> >
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=14357
> >
> > NestableException [in Beta 1 apparantly] prints the stack trace with the
> > most relevant error at the bottom and not the top, as is common in most
> > app's.
> >
> > Does anyone know if this was fixed and the bug not closed, or if it's
> > still an issue?
> >
> > The bug-creator's suggestion is a system property. Obviously this has
> > serious issues and probably isn't acceptable. How else can it be solved?
> >
> > Hen
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [lang] Bug #14357

Posted by Max Rydahl Andersen <ma...@eos.dk>.
I'm the bug-creator and if the usage of system property is unacceptable,
then i'll
suggest NestableException should be changed to conform better to how JDK 1.4
prints
exception - not just to be "complaint", but just to do the most reasonably
expected thing...which is: Print the top-most exception first, and print the
lowest last.

/max

----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Thursday, January 16, 2003 9:16 PM
Subject: [lang] Bug #14357


> I'd like to get this bug/issue dealt with.
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=14357
>
> NestableException [in Beta 1 apparantly] prints the stack trace with the
> most relevant error at the bottom and not the top, as is common in most
> app's.
>
> Does anyone know if this was fixed and the bug not closed, or if it's
> still an issue?
>
> The bug-creator's suggestion is a system property. Obviously this has
> serious issues and probably isn't acceptable. How else can it be solved?
>
> Hen
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>