You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Igor Vaynberg <ig...@gmail.com> on 2008/03/13 01:43:30 UTC

WICKET-1418

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

Re: WICKET-1418

Posted by Frank Bille <fr...@apache.org>.
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 <se...@sebster.com>
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 <ig...@gmail.com>
> > 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 <fr...@apache.org>
> >> 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 <
> igor.vaynberg@gmail.com
> >>>
> >>>  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
> >>>  >
> >>>
> >
>

Re: WICKET-1418

Posted by Sebastiaan van Erk <se...@sebster.com>.
Igor Vaynberg wrote:
> they check in getcause() again because the field cause is actually
> initialized to 'this' not 'null' :| wonder why that is...
> 
> -igor

Hmm, guess it's so that you can only set the cause once. Since you can't 
set it to this they're using (cause == this) as a test to see if the 
cause is set. Actually kind of makes sense, even though I think it's 
confusing and lousy design. :-)

Regards,
Sebastiaan

> 
> On Thu, Mar 13, 2008 at 9:00 AM, Sebastiaan van Erk <se...@sebster.com> 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 <ig...@gmail.com>
>>  > 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 <fr...@apache.org>
>>  >> 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 <igor.vaynberg@gmail.com
>>  >>>
>>  >>>  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
>>  >>>  >
>>  >>>
>>  >
>>

Re: WICKET-1418

Posted by Igor Vaynberg <ig...@gmail.com>.
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 <se...@sebster.com> 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 <ig...@gmail.com>
>  > 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 <fr...@apache.org>
>  >> 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 <igor.vaynberg@gmail.com
>  >>>
>  >>>  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
>  >>>  >
>  >>>
>  >
>

Re: WICKET-1418

Posted by Sebastiaan van Erk <se...@sebster.com>.
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 <ig...@gmail.com>
> 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 <fr...@apache.org>
>> 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 <igor.vaynberg@gmail.com
>>>
>>>  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
>>>  >
>>>
> 

Re: WICKET-1418

Posted by Igor Vaynberg <ig...@gmail.com>.
look at source of throwable.printstacktrace(), if they are not worried
about it...

-igor

On Thu, Mar 13, 2008 at 8:51 AM, Frank Bille <fr...@apache.org> 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 <ig...@gmail.com>
>
>
> 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 <fr...@apache.org>
>  > 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 <igor.vaynberg@gmail.com
>  > >
>  > >  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
>  > >  >
>  > >
>  >
>

Re: WICKET-1418

Posted by Frank Bille <fr...@apache.org>.
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 <ig...@gmail.com>
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 <fr...@apache.org>
> 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 <igor.vaynberg@gmail.com
> >
> >  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
> >  >
> >
>

Re: WICKET-1418

Posted by Igor Vaynberg <ig...@gmail.com>.
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 <fr...@apache.org> 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 <ig...@gmail.com>
>  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
>  >
>

Re: WICKET-1418

Posted by Frank Bille <fr...@apache.org>.
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 <ig...@gmail.com>
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
>