使用CommonJS承诺：拒绝与异常

Question

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

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

在情况（1）中，因为我知道异步发生之前，我可以抛出异常。在第（2）例中，我不得不拒绝承诺。

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

关于“特殊”承诺拒绝的一些明确性也会很好;那里的用法是否与异常使用实践一对一地映射，或者我们是否也将其用于非异常故障？

Answer 1

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

这是一个例子。

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

当Q显示无效输入时，Q会使用拒绝对象调用解析器。因此，您可以证明您的API行为相似，而不是尝试修改底层库的行为。

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

Answer 2

我认为您不必担心同步情况。承诺的工作方式，当将已添加到已解决（或拒绝）的承诺时，回调应同步执行。 （好吧，至少他们在Dojo那里使用它们......）

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