为什么在 JS 中使用异常来拒绝承诺？ [关闭]

Question

我所指的规范位于http://promises-aplus.github.io/promises-spec/。

使用then() 时，您可以返回一个promise，并在需要时拒绝该promise，也可以抛出一个异常来拒绝一个promise。

为什么 api 没有以这样的方式设计，对于 then 函数，它像原始的 Promise 构造函数一样传递一个解析和拒绝函数？

在许多语言中异常很重（我也假设在 javascript 中），所以它们将它们用作流控制的选择似乎很奇怪。创建一个全新的承诺对象并返回它，只是为了拒绝它，增加了代码膨胀 IMO。如果抛出异常（例如语法错误，或者在未定义的对象上调用函数等），调试也会变得更加困难。

Answer 1

为什么 api 没有以这样的方式设计，对于 then 函数，它像原始的 Promise 构造函数一样传递一个解析和拒绝函数？

实际上，该规范中的 API 已成为各种实现之间的共识。但是，可能导致这种情况的一些要点是：

• then 是一种相当实用的方法。它的回调只应该接收一个数据参数，即promise的结果值。
• 将额外的 resolve/reject 函数传递给回调函数不适用于多参数甚至可变参数函数。
• then 通常用作普通映射函数。您只需 return 新值，不需要 resolve。
• 如果你真的想在回调中做一些异步的事情，你可以使用resolve/reject，你最好还是使用promise - 你可以简单地返回。

我曾经使用可选的resolve/reject 参数实现了一个 Promise 库，但使用起来很乏味 - 由于#4，我很少需要它们。使用它们很容易出错，你很容易忘记一些事情（比如处理错误或进度事件）——就像那些手动构造和返回从 Promise 回调解决的延迟的人一样，而不是调用 then。

异常很重，因此将它们用作流控制的选择似乎很奇怪。

它们并不是真正用于控制流（如分支、循环等），而是用于异常处理：rejections are exceptional。大多数 Promise 开发人员希望将它们实现为同步（阻塞）代码的替代方案——其中 IO 总是抛出异常，因此他们对此进行了调整。拒绝仍然被解释为与try … catch 等效的异步，尽管它们的一元性质可以以更强大的方式和更高级别的应用程序使用。

创建一个全新的 Promise 对象并返回它，只是为了拒绝它，这会增加 IMO 的代码膨胀。

return new RejectedPromise(…)、return reject(…) 和 throw Error(…) 之间没有太大区别。

如果抛出异常（例如语法错误，或者在未定义的对象上调用函数等），调试也会变得更加困难

大多数 Promise 开发人员实际上似乎将此视为一个优势 - 即使在异步代码中（意外）异常也会被自动捕获，因此可以对其进行处理而不是破坏程序（不被注意）。另见exception handling, thrown errors, within promises 和acceptable promise pattern for 'LOUD' errors?。