error signal

Hi,

I found a peace of code I don't understand:

It's in the Glorp code.

        error signal = true
                ifTrue:
                        [self reset.
                        self logout.
                        self reLogin.
                        exception restart]

This code comes from VW. Is the signal method implemented
differently under VW. In squeak the "error signal" itself
throws the error so there is no ifTrue: evaluation, right?

thanks,

Norbert

Hi Norbert,

2007/5/7, Norbert Hartl <[hidden email]>:
Are you sure that 'error' is an instance of Exception or one of its
subclasses? Maybe it's something else.

Moreover, I don't see the point of 'something = true ifTrue:'. Why
not: 'something ifTrue:'?

--
Damien Cassou

On Mon, 2007-05-07 at 16:26 +0200, Damien Cassou wrote:
No, it is

handleError: exception for: command
        | errorClass error |
        errorClass := command isReadCommand
                ifTrue: [GlorpDatabaseReadError]
                ifFalse: [GlorpDatabaseWriteError].
        error := errorClass new.
        error command: command.
        error databaseError: (self innerExceptionFor: exception).
        error accessor: self.
        error signal = true
                ifTrue:
                        [self reset.
                        self logout.
                        self reLogin.
                        exception restart]
                ifFalse: [error return: nil].

And GlorpDatabaseReadError has Error as super super class.

>
> Moreover, I don't see the point of 'something = true ifTrue:'. Why
> not: 'something ifTrue:'?
>
Me neither but I didn't write it ;) And it is no problem so far.

Norbert

>Moreover, I don't see the point of 'something = true ifTrue:'. Why
>not: 'something ifTrue:

I guess it is to ensure that something is a boolean AND is true. Had the code been:

something ifTrue:[]

and something was not a boolean, the behaviour would vary between Smalltalks.

Cheers,

James

I didn't write the code but as a warning it's not always a good idea to
remove this type of pattern.  I have seen code like this when the result of
something is not always a Boolean.  Most of the time the results are true
false or nil, but sometimes something returns an object or a Boolean.  Most
of the time it can be rewritten to return only a Boolean which would be the
right solution but I've seen some pretty bad code that is better left then
mucked with.  (Again I haven't looked to see if this is the case with this
Glorp code)

As you point out it is usually just bad coding but once bitten ...

Ron Teitelbaum

>> Moreover, I don't see the point of 'something = true ifTrue:'. Why
>> not: 'something ifTrue:'?
>>
>Me neither but I didn't write it ;) And it is no problem so far.

If the "something" in 'something = true ifTrue:' is not a boolean, the code will
proceed as if "something" was false and not cause a DNU.  A common test when the
value of "something" can't be controlled.

Lou
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:[hidden email] http://www.Keystone-Software.com

2007/5/7, Norbert Hartl <[hidden email]>:
I think I understand (I've just read the squeak unit tests :-)).

When 'error signal' is sent, the exception is raised. The method
execution stops. Somewhere in the stack, the method should be captured
like:

[self doSomethingThatMightRaiseAGlorpDatabaseReadError]
  on: GlorpDatabaseReadError
  do: [:exc | self manageTheException.
                   exc resume: true]

or

resume: false

Then the control is sent back to where the exception has been raised.
What was passed to #resume: is returned by #signal.

--
Damien Cassou

The exception can resume, which is the only way the comparison would run. And it might not be resumed with a boolean, thus the = true test.

At 10:26 AM 5/7/2007, Damien Cassou wrote:

Hi Norbert,

2007/5/7, Norbert Hartl <[hidden email]>:

        error signal = true
                ifTrue:
                        [self reset.
                        self logout.
                        self reLogin.
                        exception restart]

This code comes from VW. Is the signal method implemented
differently under VW. In squeak the "error signal" itself
throws the error so there is no ifTrue: evaluation, right?

Are you sure that 'error' is an instance of Exception or one of its
subclasses? Maybe it's something else.

Moreover, I don't see the point of 'something = true ifTrue:'. Why
not: 'something ifTrue:'?

--
Damien Cassou