[Cuis-dev] [Ann] Refinements to Exception handling

[Andres Valloud]

I'd like to start the thought process a bit earlier than that.  Starting 
the cleanup commits us to the notion that exception handler blocks must 
not have non-local returns.  I think like 99.9% of the cases definitely 
should not, and I also suspect that's the impression we will get as soon 
as we start cleaning up the mess.  However, that's like *my* opinion, 
and I am not a representative sample here.

So, given that Hernan said he was also going to look into this, I'd like 
to give those interested the room to maneuver and explore the solution 
space in peace.

Let's start with a problem statement, which I will send in a new mail.

Andres.

On 10/13/19 18:11, Phil B wrote:
> Andres,
> 
> On Sun, Oct 13, 2019 at 8:47 PM Andres Valloud via Cuis-dev 
> <cuis-dev at lists.cuis.st <mailto:cuis-dev at lists.cuis.st>> wrote:
> 
>     One of the methods that won't work due to the closure indirection you
>     mention is displayWorldSafely.  What a mess :(.
> 
>     This method also illustrates the problem I referred to earlier:
>     there is
>     code written in such a way that changing it demands too much energy.
>     The system users shouldn't be held hostage by the system's own code.
> 
> 
> Yup, right now I suspect the image is going to be largely unusable as is.
> 
> 
>     Maybe if we split the work it won't be that bad to clean up.  One
>     way or
>     the other, that work should have been done before pushing out the
>     changes, as you well note.
> 
> 
> I suspect that the majority of cases will be trivial to fix.  Some 
> however...
> 
> 
>     I think the best way to proceed is to revert the changes for now,
>     decide
>     calmly what we will do about this (i.e. without the rush to cobble some
>     random patch together), then do that.
> 
> 
> Agreed.  The scope makes this a non-trivial change... let's neither rush 
> nor abandon it.  Just revert it and build the tooling we need to 
> understand the scope of it more fully.  It's entirely possible that 95% 
> of the cases are trivial and 5% are problematic... that's not a deal-killer.
> 
> A couple ideas:
> 
> 1) How about a changeset that just starts flagging senders of these 
> 'tainted' do: blocks in the background? (i.e. don't halt or spew 
> Transcript messages, just keep a collection that tracks occurrences in a 
> running image when logging is enabled)  That way we can load whatever 
> packages (either github or private), run tests, use the image for a 
> while etc. and get a better idea of what needs to be looked at.
> 
> 2) In thinking about the scenario of blocks being passed parameters for 
> error handlers, we might see some crazy stuff out in the wild that will 
> require non-trivial restructuring to fix... and as you mention, maybe 
> some of them we will decide aren't worth fixing.  Perhaps we want to 
> have a #on:taintedDo: method that allows non-local returns for those 
> cases?  That would allow us to move forward for the default and likely 
> vast majority of cases while also having flagged, minimized and 
> contained the remaining problematic use cases.