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