Hi Christoph,
I think I remember… My original interpretation of ANSI about sending #signal to an existing exception resulted in Kernel-jar.1407. However, later I noticed this wording in #messageText section:
“Subsequent sends of the message #messageText to a signaled exception generated by sending the message #signal to the receiver of this message will also return this value.”
… this “generated by” lead me to a more limited/conservative interpretation that is currently in the Trunk.

I believe Kernel-jar.1407 could be considered an extension of ANSI specification - your example indicates it’d be probably more logical or practical than the current one. I haven’t seen re-sending signal to existing exceptions implemented in other systems though.

How about to try after the release? :)
Thanks for bringing this up!
Best,
jaromir


From: Jaromir Matas<mailto:mail at jaromir.net>
Sent: Friday, June 10, 2022 17:18
To: The general-purpose Squeak developers list<mailto:squeak-dev at lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re-signalling an already signaled exception

Hi Christoph,

Thanks for the example! This was actually my original idea how re-signaling an existing exception should work :) It’s implemented in Kernel-jar.1407 (now in Treated) - check it out… it really returns
`Key not found: plonk`
as you would expect too.
Unfortunately I can’t recall why I went with the less ambitious Kernel-jar.1446 (now in Trunk) eventually.
If you find this more reasonable, why not try to revive it?
Thank you,
best,
Jaromir

From: christoph.thiede at student.hpi.uni-potsdam.de<mailto:Christoph.Thiede at student.hpi.uni-potsdam.de>
Sent: Friday, June 10, 2022 13:30
To: squeak-dev at lists.squeakfoundation.org<mailto:squeak-dev at lists.squeakfoundation.org>
Subject: Re: [squeak-dev] Re-signalling an already signaled exception

Hi Jaromir,

Thanks for working on this! I'm possibly a bit late on the party, but I noticed that current #signal only keeps the messageText, not any other custom properties of an exception. I'm not sure whether this is the expected behavior. :)

Think of this revised example:

    [(KeyNotFound key: #plonk) signal] on: Error do: [:ex |
        [ex signal] on: KeyNotFound do: [:ex2 | Transcript show: ex2]]

It will print out "Key not found: nil" to the Transcript, instead of printing the original key.

Without diving deeper into this discussion, my first impression would have been that some kind of #freshCopy (maybe with a better name?) would be a more holistic approach to honor any state in subclasses of Exception. What do you think? :-)

Best,
Christoph

---
Sent from Squeak Inbox Talk<https://github.com/hpi-swa-lab/squeak-inbox-talk>

On 2022-02-06T11:42:46+01:00, mail at jaromir.net wrote:

> Hi,
> just an update: I've sent a proposal to the Inbox: Kernel-jar.1446 with the following code:
>
> signal
>     "Ask ContextHandlers in the sender chain to handle this signal. The default is to execute and return my defaultAction.
>     Sending #signal to an already signaled exception generates a new exception of the same type with the same messageText"
>
>     signalContext ifNotNil: [^self class signal: messageText].
>     signalContext := thisContext contextTag.
>     ^(thisContext nextHandlerContextForSignal: self) handleSignal: self
>
> If possible I'd like to withdraw my previous contribution to #signal making repeated #signal sends equivalent to sending #outer, to prevent future code from using that misleading approach. Subsequent #signal sends are NOT equivalent to #outer and they have their own subtly different meaning discussed here - provided my interpretation of ANSI is right this time :)
>
> Thanks for your time and apologies for previous confusion.
>
> best,
> Jaromir
> ^[^
> --
> Sent from Squeak Inbox Talk
>
> On 2022-02-05T18:48:39+01:00, mail at jaromir.net wrote:
>
> > Hi Chris,
> >
> > On 2022-02-04T17:11:35-06:00, asqueaker at gmail.com wrote:
> >
> > > Hi Jaromir,
> > >
> > > Here's a motivation example:
> > > >
> > > > [1/0] on: Error do: [:ex |
> > > > [ex signal] on: ZeroDivide do: [Transcript show: #ZeroDivide]
> > > > ]
> > > >
> > > > Would you expect this code to work and pick up the ZeroDivide handler?
> > > >
> > > ...
> > >
> > > > The point or a use case is to provide additional (finer, more specific)
> > > > handlers inside the general handler rather than wrap the general handler
> > > > inside more specific handlers. More specific handlers can even be inside a
> > > > method so the readability would not degrade.
> > > >
> > >
> > > I was able to do it by creating a new exception instance and signaling it:
> > >
> > > [1/0] on: Error do: [: err |
> > > [err copy signal] on: ZeroDivide do: [Transcript show:
> > > #ZeroDivide] ]
> > >
> > > I don't know about #copy, though, you might want to implement your own
> > > special #freshCopy that throws out the signalContext, handlerContext and
> > > outerContext, but the above "worked". :)
> > >
> >
> > Precisely, it crossed my mind too and yes, it has to be a "fresh" copy with blank instance variables (except messageText). A simple copy fails tests with nested outer etc...
> >
> > I've checked ANSI again and they say, quote: [5.5.3.1 messageText][...] Subsequent sends of of the message #messageText to a signaled exception generated by sending the message #signal to the receiver of this message [note: the receiver is an exception instance] will also return this value.
> >
> > So what I'm actually looking for is this: (and it's equivalent to the "fresh" copy idea)
> >
> > [1/0] on: Error do: [: err |
> > [err class signal: err messageText] on: ZeroDivide do: [Transcript show: #ZeroDivide] ]
> >
> > If I'm interpreting ANSI's intention correctly then we could update our #signal like this:
> >
> > signal
> >     "Ask ContextHandlers in the sender chain to handle this signal. The default is to execute and return my defaultAction.
> >     Signaling an already signaled exception is interpreted as signaling a new exception of the same type with the same messageText"
> >
> > -    signalContext ifNotNil: [^self outer].
> > +    signalContext ifNotNil: [^self copy signal: self messageText].
> >     signalContext := thisContext contextTag.
> >     ^(thisContext nextHandlerContextForSignal: self) handleSignal: self
> >
> > It was my idea last year to make subsequent sends of #signal to an already signaled exception equivalent to #outer and now I can see it was wrong and I'd like to really fix it this time :) All test are green, even the ones in Tests-jar.464.
> >
> > Thanks, Chris, for discussing this.
> >
> > best,
> > Jaromir
> > ^[^
> > --
> > Sent from Squeak Inbox Talk
> >
> >
>
>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220610/efdd0b6e/attachment.html>