CommonJS 承诺的使用：拒绝与异常答案

【问题标题】：Use of CommonJS promises: rejection vs. exceptionsCommonJS 承诺的使用：拒绝与异常
【发布时间】：2011-11-20 07:49:27
【问题描述】：

我有一个函数，downloadAsync()，它返回一个 CommonJS 承诺（使用 Q）。它可能会以两种方式失败：

在情况 (1) 中，由于我在异步发生之前就知道，我可以抛出异常。在情况（2）中，我不得不拒绝承诺。

我的问题是，我的 API 是否应该统一并始终通过拒绝承诺来表示错误？或者我应该为立即确定的无效状态条件抛出异常？再举一个例子，如果用户向我传递了一个无效的参数，那么抛出错误似乎比拒绝承诺更明智。

澄清一下“异常”的承诺拒绝究竟是怎样的，也很好；那里的用法是否与异常使用实践一一对应，还是我们也将其用于非异常故障？

【问题讨论】：

【解决方案1】：

如果您想知道当您的函数（实现 Q）在呈现可以同步检测到的无效输入时应该做什么，我查看了 Q 的源代码，看看 Q 做了什么。

这是一个例子。

if (fallback === undefined) {
    fallback = function (op) {
        return reject("Promise does not support operation: " + op);
    };
}

当 Q 出现无效输入时，Q 使用拒绝对象调用解析器。因此，您可以合理地让您的 API 行为相似，而不是尝试修改底层库的行为。

另外，从使用您的 API 的任何人的角度来看它。他们是想开发和维护两个异常处理代码路径，还是一个？

【讨论】：

我同意。规范化您的代码以仅提供一个控制流路径供您的消费者处理是很好的。在这种情况下，我总是会返回一个承诺，尽管是一个被拒绝的承诺。然后，Q 保证必须在未来的滴答中观察到分辨率。
@Kris：只有我这样做downloadAsync().then(...).end()，对吧？如果我省略.end()，根据我的理解，它不会知道抛出。

【解决方案2】：

我认为您不必担心同步情况。 Promise 的工作方式是，当将它们添加到已解决（或拒绝）的 Promise 时，回调应该同步执行。（嗯，至少他们在我使用它们的 Dojo 中这样做......）

区分拒绝/异常的唯一原因是，如果抛出一个 Promise 对您的应用程序实际上很重要，因为我认为您不能从 Promise 回调中抛出异常。（再次重申，这是 Dojo 的承诺，不是 100% 确定你的工作方式......）

【讨论】：