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

mail at jaromir.net mail at jaromir.net
Sat Jan 29 20:43:17 UTC 2022


Hi Jakob, 
	a correction:

> > 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. 

Sorry, ignore me please, no class method indeed, but something like this:

resignalAs: replacementException
	"Abort an exception handler and signal an alternative exception in place of the receiver.
	 Allow an exception class as replacementException as an extension of ANSI specification:
		[1/0] on: Error do: [:ex | ex resignalAs: Warning new]    <--- ANSI compliant
		[1/0] on: Error do: [:ex | ex resignalAs: Warning]           <--- Squeak extension"

	(replacementException isKindOf: Exception class) ifTrue: [
		self resignalAs: replacementException new].
	signalContext restartWithNewReceiver: replacementException

a bit ugly... Or keep it simple, no extension?

resignalAs: replacementException
	"Abort an exception handler and signal an alternative exception in place of the receiver."

	signalContext restartWithNewReceiver: replacementException

best,
~~~
^[^    Jaromir

Sent from Squeak Inbox Talk

On 2022-01-29T20:18:40+01:00, mail at jaromir.net wrote:

> 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