Ahh, I guess I just remembered how a throwable looks like in the debugger
(cause == this). I wonder why we do the cause != cause.getCause in
Strings.toString? Perhaps someone had the same debugger experience and
didn't look at the implementation of getCause.
Frank
On Thu, Mar 13, 2008 at 5:00 PM, 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
> >>> >
> >>>
> >
>
