VA return from #ensure: 
Author Message
 VA return from #ensure:

Unlike VSE, VAST forbids an explicit return from either the receiver block of a #when:do:
or the handler block ("...unpredictable results."  Programmer's Reference, page 36).  Does
the same restriction apply to #ensure: and #ifCurtailed: also built on #valueOnReturnDo:
documented on page 57 but with no such restriction mentioned?

John



Wed, 18 Jun 1902 08:00:00 GMT  
 VA return from #ensure:


Quote:

>Unlike VSE, VAST forbids an explicit return from either the receiver block of a #when:do:
>or the handler block ("...unpredictable results."  Programmer's Reference, page >36).  Does
>the same restriction apply to #ensure: and #ifCurtailed: also built on #valueOnReturnDo:
>documented on page 57 but with no such restriction mentioned?

I tried these cases and here is what I got (results are shown on the
following line):

[ 2 ] ensure: [ 3 ]
2

[ 2 ] ensure: [ ^3 ]
3

[ 2 ] ifCurtailed: [ 3 ]
2

[ 2 ] ifCurtailed: [ ^3 ]
2

[ 2/0 ] ifCurtailed: [ 3 ]
walkback

[ 2/0 ] ifCurtailed: [ ^3 ]
walkback, then: 3

Note that you can exit a handler block with a value by using:

[ 2 / 0 ] when: ExError do: [ :signal | signal exitWith: 0 ]
0

Dave

_____________________________________________
David N. Smith
IBM T J Watson Research Center, Hawthorne, NY

Home Page: http://www.dnsmith.com/
_____________________________________________
Any opinions or recommendations are those
of the author and not of his employer.



Wed, 18 Jun 1902 08:00:00 GMT  
 VA return from #ensure:

Hi Dave,

I get those results too; also

  [ Transcript cr; show: 'start'.
    1 = 1 ifTrue: [^'Hello']
  ] ensure: [Transcript cr; show: 'ensured finish']
 'Hello'

and

  [ Transcript cr; show: 'start'.
    1 = 1 ifTrue: [^'Hello']
  ] ifCurtailed: [Transcript cr; show: 'curtailed']
 'Hello'

do what you would expect - every time so far - but so does

  [ [  1 = 1 ifTrue: [^'Hello'].  "or comment out to test the exception handling"
          OrderedCollection new removeFirst.
          Transcript cr; show: 'no error found'  "never get here"
    ] ifCurtailed:
          [ Transcript cr; show: 'curtailed']
  ] when: ExAll
        do: [:sig | Transcript cr; show: 'error'.
                  sig exitWith: nil
                ] 'Hello'

Is it guaranteed?  The warning on page 36 about "unpredicatable results" and not to return
from the receiver of a #when:do: is quite definite, and both constructs are built on
#valueOnReturnDo:

Regards,
John
Logic Arts Ltd
http://www.logicarts.com


Quote:

>I tried these cases and here is what I got (results are shown on the
>following line):

>[ 2 ] ensure: [ 3 ]
>2

>[ 2 ] ensure: [ ^3 ]
>3

>[ 2 ] ifCurtailed: [ 3 ]
>2

>[ 2 ] ifCurtailed: [ ^3 ]
>2

>[ 2/0 ] ifCurtailed: [ 3 ]
>walkback

>[ 2/0 ] ifCurtailed: [ ^3 ]
>walkback, then: 3

>Note that you can exit a handler block with a value by using:

>[ 2 / 0 ] when: ExError do: [ :signal | signal exitWith: 0 ]
>0

>Dave

>_____________________________________________
>David N. Smith
>IBM T J Watson Research Center, Hawthorne, NY

>Home Page: http://www.dnsmith.com/
>_____________________________________________
>Any opinions or recommendations are those
>of the author and not of his employer.



Wed, 18 Jun 1902 08:00:00 GMT  
 VA return from #ensure:


Quote:


>>Unlike VSE, VAST forbids an explicit return from either the receiver block of
> a #when:do:
>>or the handler block ("...unpredictable results."  Programmer's Reference,
> page >36).  Does
>>the same restriction apply to #ensure: and #ifCurtailed: also built on
> #valueOnReturnDo:
>>documented on page 57 but with no such restriction mentioned?

My guess would be that this is an anachronism. VisualAge 2.0 definitely did
not allow this and it was, as far as I know, fixed in 3.0. Maybe it's not
reliable, but I've not had any problems with it since.

Quote:
>I tried these cases and here is what I got (results are shown on the
>following line):

>[ 2 ] ensure: [ 3 ]
>2

etc.

I would have though the more interesting case was
    [^2] ensure: [<something with side effects>].
This seems to work, and the same for ifCurtailed:.

--

The Object People                   http://www.objectpeople.com                  
613.225.8812(v) 613.225.5943(f)    Skinheads for Smalltalk!

the xjava files - fight the future



Wed, 18 Jun 1902 08:00:00 GMT  
 VA return from #ensure:

Quote:





>>>Unlike VSE, VAST forbids an explicit return from either the receiver
block of
>> a #when:do:
>>>or the handler block ("...unpredictable results."  Programmer's
Reference,
>> page >36).  Does
>>>the same restriction apply to #ensure: and #ifCurtailed: also built on
>> #valueOnReturnDo:
>>>documented on page 57 but with no such restriction mentioned?

>My guess would be that this is an anachronism. VisualAge 2.0 definitely did
>not allow this and it was, as far as I know, fixed in 3.0. Maybe it's not
>reliable, but I've not had any problems with it since.

The problem that I experienced with returns from exception handler blocks
was that it prevented garbage collection of objects that have no other
references but are on the stack because a return value from an exception
handler block is anticipated. At least that was my take on it. I would
expect it to be an issue for later versions of VA/IBMST but I'm not sure
because I haven't seen or used returns from exception handler blocks for
several years. It isn't a problem that is very easy to detect. You typically
find it only when you are tracking down other more serious programming style
problems that affect garbage collection.

Paul Baumann



Wed, 18 Jun 1902 08:00:00 GMT  
 VA return from #ensure:

Quote:






>>>>Unlike VSE, VAST forbids an explicit return from either the receiver
>block of
>>> a #when:do:
>>>>or the handler block ("...unpredictable results."
...
>>My guess would be that this is an anachronism. VisualAge 2.0 definitely did
>>not allow this and it was, as far as I know, fixed in 3.0. Maybe it's not
>>reliable, but I've not had any problems with it since.

>The problem that I experienced with returns from exception handler blocks
>was that it prevented garbage collection of objects that have no other
>references but are on the stack because a return value from an exception
>handler block is anticipated. At least that was my take on it. I would
>expect it to be an issue for later versions of VA/IBMST but I'm not sure
>because I haven't seen or used returns from exception handler blocks for
>several years. It isn't a problem that is very easy to detect. You typically
>find it only when you are tracking down other more serious programming style
>problems that affect garbage collection.

Hmmm. That sounds like correct behaviour, albeit probably unanticipated. If
the stack needs to be kept around then it counts as a reference, and those
objects shouldn't be garbage-collected. This sounds like the more general
problem of blocks being stored in places and carrying around a whole lot of
other baggage you didn't expect. Or maybe I'm not understanding the problem.

Anyone responding, please copy me in e-mail, I'll be out of newsreading range
for a couple of weeks.

--

The Object People                   http://www.objectpeople.com                  
613.225.8812(v) 613.225.5943(f)    Skinheads for Smalltalk!

the xjava files - I want to believe



Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. question on return from blocks and ensure: blocks

2. Return from ensure

3. [VA] VA Process Browser 1.5 Update Available

4. VA: Several VA application blocking each other ...

5. Question: VA OS/2 or VA for Windows?

6. VA: Problem with ODBC Text driver for VA 3.0

7. Any Problems Porting VA 2.0 code to VA 3.0

8. [VA] VA Process Browser 1.4 Update Available

9. VA 5 and VA 5.5 Packaging headless

10. [VA] VA SUnit Browser 3.0.1 Update Available

11. [VA] VA Process Browser 1.2 Update Available

12. "VisualAge-Immediate Contract-Mutiple-MD-VA",md.jobs,va.jobs,dc.jobs

 

 
Powered by phpBB® Forum Software