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

[Phil B]

Andres,

On Sun, Oct 13, 2019 at 8:47 PM Andres Valloud via Cuis-dev <
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20191013/fc673f99/attachment.htm>