they check in getcause() again because the field cause is actually
initialized to 'this' not 'null' :| wonder why that is...
-igor
On Thu, Mar 13, 2008 at 9:00 AM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
> If you look at throwable you'll see:
>
> public Throwable getCause() {
> return (cause==this ? null : cause);
> }
>
> Thus if you use getCause() you should never get get a loop. They also
> have stuff to avoid the situation (it seems almost like a class
> invariant that cause != this, but then why check in getCause()?), i.e.:
>
> public synchronized Throwable initCause(Throwable cause) {
> if (this.cause != this)
> throw new IllegalStateException("Can't overwrite cause");
> if (cause == this)
> throw new IllegalArgumentException("Self-causation not
> permitted");
> this.cause = cause;
> return this;
> }
>
> Regards,
> Sebastiaan
>
>
>
> Frank Bille wrote:
> > If you look at Strings.toString(Trowable) then it also checks that cause !=
> > cause.getCause() :-)
> >
> > Frank
> >
> > On Thu, Mar 13, 2008 at 4:38 PM, Igor Vaynberg <[EMAIL PROTECTED]>
> > wrote:
> >
> >> heh, i really really dont think so.
> >>
> >> if that was ever true you would have some huge log files because
> >> printing out a stacktrace would go into an infinite loop too :)
> >>
> >> -igor
> >>
> >>
> >>
> >> On Thu, Mar 13, 2008 at 2:22 AM, Frank Bille <[EMAIL PROTECTED]>
> >> wrote:
> >>> As far as I can see you would never get out of the loop because
> >>> cause.getCause() will at some point return itself if I remember
> >> correctly.
> >>> Frank
> >>>
> >>> On Thu, Mar 13, 2008 at 1:43 AM, Igor Vaynberg <[EMAIL PROTECTED]
> >>>
> >>> wrote:
> >>>
> >>>
> >>>
> >>> > i attached a patch (untested) which solves it in a very general ways.
> >>> > let me know if you guys see any problems with it.
> >>> >
> >>> > -igor
> >>> >
> >>>
> >
>
