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

Hi Jakob, all,

I give up this experiment of mine; I've realized using #restartWithNewReceiver is tricky and very non-OOP: replacing a receiver with an object of a different type introduces unexpected consequences and checking the type of the replacement object is so not-object-oriented; the best I could come up with is:

resignalAs: replacementException "Signal an alternative exception in place of the receiver."

(replacementException isKindOf: Exception class) ifTrue: [^self resignalAs: replacementException new]. (replacementException isKindOf: Exception) ifFalse: [^self error: 'wrong replacementException type']. signalContext restartWithNewReceiver: replacementException

This would be a clean implementation of ANSI's #resignalAs with a nice stack when debugging; compare with the confusing stack currently produced for e.g.:

[self error] on: Error do: [:ex | ex resignalAs: Warning new]

Besides, the current implementation allows nonsense like this evaluate silently:

[self error] on: Error do: [:ex | ex resignalAs: Semaphore new]

but it probably doesn't do much harm and doesn't justify changing the current simple implementation.

So unless someone sees any value in the above implementation I won't clutter the Inbox :)

Thanks.

best, Jaromir ^[^ -- Sent from Squeak Inbox Talk

On 2022-01-29T21:43:17+01:00, mail@jaromir.net wrote:

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

Hi Vaidotas, Thanks for the feedback; great example… I’ll investigate. I plan to revisit exceptions later and let you know :) Thanks again, Jaromir

From: Vaidotas Didžbalismailto:vaidasd@gmail.com Sent: Monday, March 7, 2022 17:15 To: The general-purpose Squeak developers listmailto:squeak-dev@lists.squeakfoundation.org Subject: Re: [squeak-dev] Slightly incorrect implementation of #resignalAs: ??

Hello Jaromir, all, Change affects re-signaling exceptions of the same kind, line below falls into endless loop in Trunk. It works differently in Squeak 5.3 or 4.2: [Error new signal: 'some error'] on: Error do: [:e | e resignalAs: (DomainError new messageText: 'some domain error')]. regards, Vaidotas

On Fri, Feb 4, 2022 at 4:15 PM <mail@jaromir.netmailto:mail@jaromir.net> wrote: Hi Jakob, all,

I give up this experiment of mine; I've realized using #restartWithNewReceiver is tricky and very non-OOP: replacing a receiver with an object of a different type introduces unexpected consequences and checking the type of the replacement object is so not-object-oriented; the best I could come up with is:

resignalAs: replacementException "Signal an alternative exception in place of the receiver."

(replacementException isKindOf: Exception class) ifTrue: [^self resignalAs: replacementException new]. (replacementException isKindOf: Exception) ifFalse: [^self error: 'wrong replacementException type']. signalContext restartWithNewReceiver: replacementException

This would be a clean implementation of ANSI's #resignalAs with a nice stack when debugging; compare with the confusing stack currently produced for e.g.:

[self error] on: Error do: [:ex | ex resignalAs: Warning new]

Besides, the current implementation allows nonsense like this evaluate silently:

[self error] on: Error do: [:ex | ex resignalAs: Semaphore new]

but it probably doesn't do much harm and doesn't justify changing the current simple implementation.

So unless someone sees any value in the above implementation I won't clutter the Inbox :)

Thanks.

best, Jaromir ^[^ -- Sent from Squeak Inbox Talk

On 2022-01-29T21:43:17+01:00, mail@jaromir.netmailto:mail@jaromir.net wrote:

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<http://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<http://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<http://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
> > >
> >
> >
>
>