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

Marcel Taeumel marcel.taeumel at hpi.de
Tue Feb 13 14:08:39 UTC 2018


... for me, I do not see or use the promise object. It is just a regular (even if deferred) message send. Thus, the debugger should appear as usual for other message sends.

Best,
Marcel
Am 13.02.2018 15:00:04 schrieb Marcel Taeumel <marcel.taeumel at hpi.de>:
I would prefer to see the debugger in such a case, unless the user makes use of #whenRejected: explicitely.

I use future sends to perform frequent checks/tasks in the UI process. On each check, I decide whether to continue polling or not. I do not want to use Morphic alarms directly for such a case.


You can avoid the debugger in the case of MorphicProjects like this:

[
1 future / 0.
"If needed, wait with a delay here."
Project current world doOneCycle.
]
on: ZeroDivide
do: [:err | ]


Best,
Marcel
Am 13.02.2018 13:59:11 schrieb Tony Garnock-Jones <tonyg at leastfixedpoint.com>:
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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180213/cf68c4a6/attachment.html>


More information about the Squeak-dev mailing list