W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

RE: Promises: final steps

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Thu, 5 Sep 2013 16:04:29 +0000
To: Kevin Smith <zenparsing@gmail.com>, Kris Kowal <kris.kowal@cixar.com>
CC: "public-script-coord@w3.org" <public-script-coord@w3.org>, "www-dom@w3.org" <www-dom@w3.org>, es-discuss <es-discuss@mozilla.org>
Message-ID: <B4AE8F4E86E26C47AC407D49872F6F9F918B3D85@BY2PRD0510MB354.namprd05.prod.outlook.com>
From: Kevin Smith [zenparsing@gmail.com]

> Indeed, for a non-GUI embedding like Node, they *must* be debuggable using just a console.

This is an important point. A provisional idea that preserves our desire to not introduce new features to promises themselves, requiring user choice at authoring time, might be some kind of `console.unhandledRejections()` function which returns you a snapshot of the current unhandled rejections bucket.

> Another option is a static method which takes a promise and throws rejections ala done:
>
> ```js
> Promise.throw(makeSomePromise.then(...));
> ```

I find these kind of things confusing. RSVP did something similar, introducing

```js
RSVP.rethrow = r => setImmediate(() => throw r);
```

so that you write

```js
somePromise.then(...).catch(RSVP.rethrow); // actually RSVP uses `fail`.
```

It's not clear to me why this, or your `Promise.throw`, is better than

```js
somePromise.done(...)
// or
somePromise.then(...).done()
```
Received on Thursday, 5 September 2013 16:05:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:50 UTC