[squeak-dev] [ReviewRequest] Error-handling and use of `future`

Tony Garnock-Jones tonyg at leastfixedpoint.com
Tue Feb 13 12:59:02 UTC 2018


Hi all,

At the moment, if I printIt

	(1 future / 0)

this results in a Promise, as expected.

Separately, when the UI process next runs (almost immediately), it ends
up signalling ZeroDivide, causing a debugger to open.

It does not either resolve or reject the promise.

The promise remains pending forever, when it should be rejected.

The attached changeset is small and simple, and fixes this problem. It
spans several packages - Morphic, System, Kernel and KernelTest - which
is why it's a changeset and not a bunch of submissions to the inbox.

If people could take a look over it, that'd be great! If the consensus
is that the change is an improvement, I'll commit to MC and update trunk.

I have specific questions:

1. How should unhandled errors by `future` sends be treated? The current
code, and the code after the attached changeset, always opens a
debugger. Would it be better to *not* open a debugger, instead relying
on the user of the Promise to care about #whenRejected:? I cautiously
suggest this might be the case. (Concretely, in the language of the
changeset, all that would change is that `true` in Promise>>fulfillWith:
would become `false`.)

2. What code is using `future`? Where can I find some examples of code
that (isn't already broken and that) might break if I change the way
`future` works? It seems like `future` is not widely used at all. If
this is the case, perhaps we might be free to improve it.

3. How can we properly test errors signalled by a future send, if it
pops up a debugger that we can't suppress? See the changeset's
PromiseTest>>testFutureRejection, which currently has to be an
expectedFailure for this reason.

Tony
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FuturePromiseErrorHandling.1.cs
Type: text/x-csharp
Size: 4013 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180213/8d0362df/attachment.bin>


More information about the Squeak-dev mailing list