Ron Buckton (2013-06-19T04:55:47.000Z)
github at esdiscuss.org (2013-07-12T02:27:38.028Z)
I've often looked at Promise#then() as sugar over Promise#done() for something like: ```js Promise.prototype.then = function(resolve, reject) { return new Promise(resolver => { this.done( value => { try { resolver.resolve(resolve ? resolve(value) : value); } catch (e) { resolver.reject(e); } }, err => { try { resolver.resolve(reject ? reject(value) : value); } catch (e) { resolver.reject(e); } }); }); } ``` Promise#done() doesn't have the overhead that Promie#then does (allocating a new chained Promise), so it is more efficient if you don't need to chain. It feels easier to be more explicit with done then without, since to polyfill done requires calling something like setImmediate to raise the error to the engine/window.onerror, since throwing it in the reject handler would just result in a new rejected Promise. If we had an 'await' keyword I might find the need for done to be less important, as it would be easy to write "await p" to bubble the exception to user code. Although, 'await' would also be more efficient with 'done' rather than 'then'. If Promise#done is out, a polyfill could just have an array of unhandled exceptions that could be analyzed programmatically in user code or via the console.