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

                                        I forgot the list ... <br><div class="mb_sig"></div><div class="history_container"><p style="color: margin-top: 10px;">------ Weitergeleitete Nachricht --------<br>Von: Marcel Taeumel <marcel.taeumel@hpi.de><br>Datum: 14.02.2018 11:35:39 <br>Betreff: Re: [ReviewRequest 2] Error-handling and use of `future` <br>An: Tony Garnock-Jones <tonyg@leastfixedpoint.com><br></p><div id="__MailbirdStyleContent" style="font-size: 12pt;font-family: calibri;color: #000000">

                                        Hi Toni,<div><br></div><div>if it is a "promise", why aren't the states "kept" and "broken"? Or "delivered" and "broken"? Well, "resolve" sounds more like message lookup/sending, yet promises do actually make use of that mechanism here.</div><div><br></div><div>... #onDelivery: ... #onBreak: ...</div><div><br></div><div>:-)</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div>

                                        </div></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 14.02.2018 09:04:35 schrieb Tony Garnock-Jones <tonyg@leastfixedpoint.com>:</p>Hi Marcel,

<br>

<br>On 02/14/2018 06:58 AM, Marcel Taeumel wrote:

> could elaborate on what it means, in general, to "reject a promise"?

<br>> Does rejection directly map to the exception mechanism? Or are there

<br>> other cases?

<br>

<br>It's terminology lifted from https://promisesaplus.com/, and it is more

<br>general than the exception mechanism. One advantage of this generality

<br>is that it is able to usefully propagate failures in a concurrent system

in a way that the stack-oriented nature of exception propagation cannot.

<br>

<br>Briefly: a promise is a calculation that may yield either a result or a

<br>failure, each with an associated value. A failure value may be any

<br>value, Exception, nil, String, or otherwise. In Squeak, the "resolved"

<br>handlers are notified if the promise yields a result, and the "rejected"

handlers are notified if the promise yields a failure.

<br>

<br>The connection to exceptions is that in most cases a signaled exception

should cause a promise to yield a failure.

<br>

<br>There's a connection in the reverse direction, too: Promise>>#wait will

signal BrokenPromise if a promise yields a failure.

<br>

<br>Rejection is a new-ish (2013?) feature of Squeak promises that doesn't

<br>seem to have been properly integrated; the changes I've been making

<br>recently feel to me like more fully fleshing out the idea. One nice

<br>side-effect of the partiality of the integration of rejection is that

<br>no-one can possibly have been using it :-) leaving us free to assign

sensible semantics to it without fear of backwards-compatibility problems.

<br>

<br>Tony

<br>

                        </blockquote></div>