<div id="__MailbirdStyleContent" style="font-size: 12pt;font-family: calibri;color: #000000">

                                        I would prefer to see the debugger in such a case, unless the user makes use of #whenRejected: explicitely.<div><br></div><div>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.<br><div><br></div><div>You can avoid the debugger in the case of MorphicProjects like this:</div><div><br></div><div><div>[</div><div><span class="Apple-tab-span" style="white-space:pre">     </span>1 future / 0.</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>"If needed, wait with a delay here."</div><div><span class="Apple-tab-span" style="white-space:pre">       </span>Project current world doOneCycle.</div><div>]</div><div><span class="Apple-tab-span" style="white-space:pre">    </span>on: ZeroDivide</div><div><span class="Apple-tab-span" style="white-space:pre">       </span>do: [:err | ]</div></div><div><br></div><div><br></div><div>Best,</div><div>Marcel</div></div><div class="mb_sig"></div>

                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">

                        <p style="color: #AAAAAA; margin-top: 10px;">Am 13.02.2018 13:59:11 schrieb Tony Garnock-Jones <tonyg@leastfixedpoint.com>:</p>Hi all,

<br>

<br>At the moment, if I printIt

<br>

<br>      (1 future / 0)

<br>

this results in a Promise, as expected.

<br>

<br>Separately, when the UI process next runs (almost immediately), it ends

up signalling ZeroDivide, causing a debugger to open.

<br>

It does not either resolve or reject the promise.

<br>

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

<br>

<br>The attached changeset is small and simple, and fixes this problem. It

<br>spans several packages - Morphic, System, Kernel and KernelTest - which

is why it's a changeset and not a bunch of submissions to the inbox.

<br>

<br>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.

<br>

<br>I have specific questions:

<br>

<br>1. How should unhandled errors by `future` sends be treated? The current

<br>code, and the code after the attached changeset, always opens a

<br>debugger. Would it be better to *not* open a debugger, instead relying

<br>on the user of the Promise to care about #whenRejected:? I cautiously

<br>suggest this might be the case. (Concretely, in the language of the

<br>changeset, all that would change is that `true` in Promise>>fulfillWith:

<br>would become `false`.)

<br>

<br>2. What code is using `future`? Where can I find some examples of code

<br>that (isn't already broken and that) might break if I change the way

<br>`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.

<br>

<br>3. How can we properly test errors signalled by a future send, if it

<br>pops up a debugger that we can't suppress? See the changeset's

<br>PromiseTest>>testFutureRejection, which currently has to be an

expectedFailure for this reason.

<br>

<br>Tony

<br><br>

                        </blockquote></div>