[squeak-dev] Slightly incorrect implementation of #resignalAs: ??

mail at jaromir.net mail at jaromir.net
Sat Jan 29 19:18:40 UTC 2022


Hi Jakob,

thanks for your reply. 

The proposed change is not supposed to change the semantics of resignalAs in any way (except limiting the argument to an exception instance, not a class).

We already have 3 resignalAs tests - is this ok? Pharo/Cuis are behind Squeak and as for VW I'm not familiar with their testing just yet.

The tests are green; well, after fixing my own contribution from last year (doubleOuterResignalAsTest) where I erroneously used a class as #resignalAs's argument - what a shame :) I'll definitely send a fix of this test to the Inbox.

> As so often, the breaking of applications that relied on the
> non-standard behavior may be an obstacle.
Yes indeed, that's a pain... theoretically as a workaround a class method could be added to create an instance and send it the instance side #resignalAs. However looking at its senders this method doesn't feel like frequently used :) (VA didn't even bother to implement it, at least in the version I have)

best,
~~~
^[^    Jaromir

Sent from Squeak Inbox Talk

On 2022-01-29T18:53:24+01:00, jakres+squeak at gmail.com wrote:

> Hi Jaromir,
> 
> We should start with a test case. I agree with your interpretation of
> the standard and see no harm in an inbox submission.
> Is there some ANSI Smalltalk test suite out there that could be shared
> between the dialects?
> 
> As so often, the breaking of applications that relied on the
> non-standard behavior may be an obstacle.
> 
> Kind regards,
> Jakob
> 
> Am Sa., 29. Jan. 2022 um 17:43 Uhr schrieb <mail at jaromir.net>:
> >
> > Hi all,
> >
> > I think Squeak's implementation of #resignalAs: is not following the ANSI specification precisely. Currently it reads:
> >
> > resignalAs: replacementException
> >
> >         signalContext resumeEvaluating: [replacementException signal]
> >
> > ANSI says:
> > "
> > The active exception action is aborted and the exception environment *and the evaluation context*
> > are restored to the same states that were in effect when the receiver was originally signaled.
> > This message (i.e. resignalAs:) causes the replacementException to be treated as if it had been originally
> > signaled instead of the receiver.
> > "
> >
> > This is very similar to #retry (or #retryUsing:) specification so I'd suggest the following implementation:
> >
> > resignalAs: replacementException
> >
> >         signalContext restartWithNewReceiver: replacementException
> >
> > The current implementation leads to building the new resignaled contexts on top of the previous signal contexts (and the resignalAs context itself) instead of simply *restarting* the previous signal context with the replacement exception as the new receiver. In my opinion the suggested implementation precisely follows the ANSI specification, and is consistent with current #retry and #retryUsing: implementation - compare:
> >
> > retryUsing: alternativeBlock
> >         "Abort an exception handler and evaluate a new block in place of the handler's protected block."
> >
> >         handlerContext restartWithNewReceiver: alternativeBlock
> >
> > Other dialects: Pharo and Cuis copied Squeak's but VW implemented resignalAs: to comply with ANSI precisely.
> >
> > One consideration: the current implementation allows "exception resignalAs: Error", i.e. allows Exception class as an argument but ANSI's version requires "exception resignalAs: Error new". All senders (there are just a few) in the base image seem use "Error new" anyway.
> >
> > My arguments for are: consistency, readability and less complexity (especially while debugging)
> >
> > What do you think? Inbox it?
> >
> > best,
> > ~~~
> > ^[^    Jaromir
> >
> > Sent from Squeak Inbox Talk
> >
> 
> 


More information about the Squeak-dev mailing list