[squeak-dev] Fw: Re: [ReviewRequest 2] Error-handling and use of `future`

Marcel Taeumel marcel.taeumel at hpi.de
Wed Feb 14 10:36:32 UTC 2018


I forgot the list ... 

------ Weitergeleitete Nachricht --------
Von: Marcel Taeumel <marcel.taeumel at hpi.de>
Datum: 14.02.2018 11:35:39
Betreff: Re: [ReviewRequest 2] Error-handling and use of `future`
An: Tony Garnock-Jones <tonyg at leastfixedpoint.com>

Hi Toni,

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.

... #onDelivery: ... #onBreak: ...

:-)

Best,
Marcel
Am 14.02.2018 09:04:35 schrieb Tony Garnock-Jones <tonyg at leastfixedpoint.com>:
Hi Marcel,

On 02/14/2018 06:58 AM, Marcel Taeumel wrote:
> could elaborate on what it means, in general, to "reject a promise"?
> Does rejection directly map to the exception mechanism? Or are there
> other cases?

It's terminology lifted from https://promisesaplus.com/, and it is more
general than the exception mechanism. One advantage of this generality
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.

Briefly: a promise is a calculation that may yield either a result or a
failure, each with an associated value. A failure value may be any
value, Exception, nil, String, or otherwise. In Squeak, the "resolved"
handlers are notified if the promise yields a result, and the "rejected"
handlers are notified if the promise yields a failure.

The connection to exceptions is that in most cases a signaled exception
should cause a promise to yield a failure.

There's a connection in the reverse direction, too: Promise>>#wait will
signal BrokenPromise if a promise yields a failure.

Rejection is a new-ish (2013?) feature of Squeak promises that doesn't
seem to have been properly integrated; the changes I've been making
recently feel to me like more fully fleshing out the idea. One nice
side-effect of the partiality of the integration of rejection is that
no-one can possibly have been using it :-) leaving us free to assign
sensible semantics to it without fear of backwards-compatibility problems.

Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180214/429d22d8/attachment.html>


More information about the Squeak-dev mailing list