[Cuis-dev] On the changes to detect method returns in exception handlers

[Hernan Wilkinson]

>
> 1) Would you be opposed to a #nonLocalReturn: method on Exception?  That
> seems to me a cleaner and clearer way of doing this.  It's also more
> consistent with how Exception deals with the other scenarios.
>
>
> I think #nonLocalReturn: would be ok. Maybe a better name could be
> #methodReturn:
>

I'm against the #nonLocalReturn: or #methodReturn: :-)
I think they do not solve anything (there is no problem currently) and they
add accidental complexity that it is unnecessary.

Cheers!
Hernan


>
> 2) Doh!  I'm not sure if I did the double-signaling or if that was from
> the original OMeta code.  Either way, it was a dumb thing to do and
> entirely unnecessary in this case as your changes show.  The 'only signaled
> once!' part warrants discussion/clarification...
>
>
>>
>> Finally, I suggest adding yet another change set to Cuis that could break
>> existing but wrong code: 3924*.cs.st attached throws an error if an
>> exception is signaled twice.
>>
>
> I guess it depends on what you are saying:
>
> 1) We think signaling twice is bad form and logically inconsistent and so
> you shouldn't do it (to me that's not an error, but is something we should
> capture and *optionally* report to the user... I'm working on another
> email/changeset related to this case.)
>
> 2) In Cuis, for implementation reasons, signaling twice is an error and
> can not be done (define twice... read on...)
>
> While what you are saying re: not re-signaling logically makes sense as
> something to avoid in general, I don't see anything in the ANSI spec
> explicitly either allowing or forbidding it.[SPEC]  That's not a big deal
> as sometimes implementation decisions need to be made but I think we need
> to be very clear here on what is/isn't allowed:
>
> 1) You can't signal the exception from within its handler block (i.e. you
> can signal the exception again and/or recycle it, but only *after* the
> current signal has been handled)
>
> 2) You can't re-signal an Exception ever (i.e. you can recycle but not
> re-signal... meaning we need to have a method to clear out relevant state
> for recycling)
>
> 3) You can't re-signal or recycle an Exception ever (i.e. they are
> single-shot instances)
>
> (However we go, it seems like comments on the class and relevant methods
> are in order)
>
> Seriously, I didn't just make this up.... recycling is a real use case.
> If you read my final note on https://github.com/pbella/OMeta-Cuis, the
> 'original' OMeta implementation actually did recycle exceptions as a
> performance enhancement.  It did this by re-signaling the existing instance
> since there was no formal mechanism for recycling.  I removed the feature
> due to the implementation leaking (on the OMeta side not the Exception
> side, IIRC) and had planned to re-implement it (sans leak) at some point.
> So I'm wondering if that is something that is supported or not.
>
>
> I'm pretty sure re-signaling an exception instance while it is being
> handled shouldn't be allowed. An exception has a (single) signalContext.
> The design can't handle more than one.
>
> To enable re-signaling an already handled exception instance, I guess it
> could be enough to clear ivar 'signalContext' in the ifCurtailed: block in
> #evaluateHandlerBlock: . Then,
> 3924-SignalExceptionsOnlyOnce-JuanVuletich-2019Oct16-18h52m-jmv.1.cs.st
> would stay.
>
>
> This is all near and dear to me because, as you probably noticed,
> Exception is the spine of OMeta's control flow.  If you change/break one,
> you probably change/break the other.
>
>
> Yep. It is a good test bed.
>
>
>
>> Please review.
>> Thanks,
>>
>> --
>> Juan Vuletich
>>
>>
> Thanks,
> Phil
>
> [SPEC] Just to clarify what I mean here.  In section 5.5.4.2 they
> explicitly state in the Errors section where #outer cannot be sent from.
> If they intended #signal to not be called from somewhere in particular, I
> would expect (ok, hope) to see that indicated somewhere for #signal as
> well.  Of course specs aren't perfect and there are any number of reasons
> why this might not have been stated one way or the other.
>
>
> I'm pretty sure it was an oversight. Doing [ :ex | ex signal ] as a
> handler block is asking for trouble. How can you know it will not try to
> handle the new signal with the same handler, entering in an endless
> recursion?
>
> Thanks,
>
> --
> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3
> @JuanVuletich
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>


-- 

*Hernán WilkinsonAgile Software Development, Teaching & Coaching*
*Phone: +54-011*-4893-2057
*Twitter: @HernanWilkinson*
*site: http://www.10Pines.com <http://www.10pines.com/>*
Address: Alem 896, Floor 6, Buenos Aires, Argentina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20191017/f593d5d2/attachment-0001.htm>