domenic at domenicdenicola.com (2013-09-08T01:14:54.971Z)
Thanks for the details! This gives us an idea what a "promise monitoring" feature might look like in a browser's developer tools. I think such a feature would be really cool, but I believe that promise-using programs ought to be debuggable using just a console. Indeed, for a non-GUI embedding like Node, they *must* be debuggable using just a console. I don't think we should ship an API that is not debuggable using a console. However, I'm *not* in favor of a `done` method on the Promise prototype because of functional overlap with `then`. Another option is a static method which takes a promise and throws rejections ala done: ```js Promise.throw(makeSomePromise.then(...)); ``` Personally, I consider it a shame that promise libraries punted on the distinction between rejections and program errors, but I suppose it's too late to go there.
Hi Kris, Thanks for the details! This gives us an idea what a "promise monitoring" feature might look like in a browser's developer tools. I think such a feature would be really cool, but I believe that promise-using programs ought to be debuggable using just a console. Indeed, for a non-GUI embedding like Node, they *must* be debuggable using just a console. I don't think we should ship an API that is not debuggable using a console. However, I'm *not* in favor of a `done` method on the Promise prototype because of functional overlap with `then`. Another option is a static method which takes a promise and throws rejections ala done: Promise.throw(makeSomePromise.then(...)); Personally, I consider it a shame that promise libraries punted on the distinction between rejections and program errors, but I suppose it's too late to go there. { Kevin } -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130905/4970de3a/attachment.html>