没有。
.done 不仅可能在未来版本的规范中不受支持 - 它是不需要的。引用 Mariusz 链接到的线程:
家庭:
它仍然容易出错:如果你犯了错误,甚至一次都不遵守规则,你可能会永远沉默错误。
Mark Miller(率先提出承诺的概念):
请注意,weak-refs,希望在 ES7 中,将为我们提供我们需要的一种诊断工具来弥补这一差距。使用weak-refs,如果在没有通知任何处理程序的情况下收集了被拒绝的promise,我们可以安排它生成诊断。 Promise 实现必须将原因保留在 Promise 的执行程序(事后 gc 处理程序)中,以便在发现 Promise 已被拒绝后进行诊断报告。
Yehuda Kats 关于 RSVP 的错误处理程序:
我们在 RSVP 中采用的方法是安装一个默认抛出的未处理的 Promise 监视器。
如果您知道您将附加异步错误处理程序,则可以通过附加 noop 故障处理程序来选择特定的 Promise 退出此行为。我们可能会为此加糖(.undone :p)
根据我们的经验,将负担从每个人转移到可能想要附加异步错误处理程序的人是合适的。
而且,从规范之前的实际回购中,Domenic 说:
将通过将未处理的拒绝跟踪功能集成到开发工具中来完成工作。据我了解,大多数 TC39 人员以及我自己都认为这足以完成规范。
规范委员会不只是忽略.done,他们认为这是不必要的并且容易出错。新的现代 Promise 库会自动检测未处理的拒绝 - 其中两个示例是开创这一想法的 When Promise 和 Bluebird Promise。
.done 是一个人工制品 - 源于浏览器无法检测到未处理的拒绝。事实是 - 确定性地检测它们是不可能的,但对于绝大多数情况来说,这是完全可能的。
不相信我?打开 Firefox 并使用它的原生 Promise:
p = new Promise(function (resolve, reject) {
throw 'err';
});
// Logs as error: Unhandled error: `err`
简单地说 - firefox 使用垃圾收集钩子来确定 Promise 是否处于未处理状态,并触发默认在屏幕上写入的全局错误处理程序。
现在,问题是本机 Promise 还不是很实用 - 因为在 IE 中它们不存在,并且在 Chrome 中未处理的拒绝检测尚未实现 - 但它即将到来并且它会在那里。同时,您可以使用像 Bluebird 这样的 ES6 兼容库,它会为您进行拒绝跟踪。
如果你想完成 polyfill(我强烈推荐反对)- torazaburo 的 polyfill 有一些缺点。它在 Promise 原型上声明了一个可枚举的属性,通常这不是规范的设计方式——您应该subclass Promise 以扩展它们而不是猴子修补它们——遗憾的是,目前没有实现支持这一点.
简而言之:
- 等待原生 promise 稳定后再使用它们 - 同时您可以使用像 Bluebird 这样实现规范的库。当它稳定下来时,没有
.done 将根本不是问题。
- 利用模式检测错误 - 例如在此处查看the disposer pattern。
- 在可用时使用开发人员工具,长堆栈跟踪和异步调试是一大优势。另请注意,如果您想要有意义的堆栈跟踪,则不应抛出字符串。
祝你好运,编码愉快。