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 at 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 at 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
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220307/20c695ca/attachment.html>