2

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

  1. 该文件已经可以下载，在这种情况下我们立即知道。
  2. 下载过程可能会失败，在这种情况下我们会在一段时间后知道。

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

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

弄清楚“异常”的承诺拒绝到底是多么的好，也很好；那里的使用是否与异常使用实践一对一地映射，或者我们是否也将其用于非异常故障？

4

2 回答 2

3

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

这是一个例子。

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

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

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

于 2011-09-19T15:00:47.590 回答
0

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

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

于 2011-09-19T15:02:01.647 回答