何时拒绝/解决promise

Question

我在想什么时候我该拒绝一个promise。我发现了几个关于这个话题的问题，但找不到合适的答案。我什么时候应该拒绝promise？

本文http://howtonode.org/6666a4b74d7434144cff717c828be2c3953d46e7/promises 说：

• 解析：一个成功的promise是“已解析”的，它调用正在等待的成功侦听器，并记住为附加的未来成功侦听器解析的值。分辨率与返回值相关。

这是否原则指引？只有在出现例外情况时才拒绝promise？

但是对于一个函数，比如

findUserByEmail()

我希望函数返回一个用户，这样我就可以在不验证结果的情况下继续链

findUserByEmail()
    .then(sendWelcomeBackEmail)
    .then(doSomeNiceStuff)
    .then(etc..)

什么是最好的/常见的做法？

Answer 1

我知道你从哪里来。Q和Q文档很容易让您相信延迟/promise拒绝完全是关于异常处理的。

事实未必如此。

无论您的申请需要什么理由，延期申请都可能被拒绝。

延迟/promise都是关于处理异步流程的响应，每个异步流程都可能导致各种结果——其中一些是“成功的”，一些是“不成功的”。你可以选择拒绝你的推迟-无论出于什么原因，不管结果是名义上的成功还是不成功，也没有一个例外被抛出，无论是在javascript还是在异步过程中。

您还可以选择在异步进程上实现超时，在这种情况下，您可以选择在没有收到响应（成功或不成功）的情况下拒绝延迟。事实上，对于超时，这是您通常会选择做的事情。

Answer 2

一般来说，您可以认为拒绝类似于同步的抛出，实现类似于同步的返回。当函数以某种方式失败时，应该拒绝。这可能是超时、网络错误、输入错误等。

拒绝promise，就像抛出异常一样，对于控制流非常有用。它不一定代表一个真正意想不到的错误；它可以代表您完全预期和处理的问题：

function getProfile(email) {
  return getProfileOverNetwork(email)
    .then(null, function (err) {
      //something went wrong getting the profile
      if (err.code === 'NonExistantUser') {
        return defaultUser;
      } else if (profileCached(email)) {
        return getProfileFromCache(email);//fall back to cached profile
      } else {
        throw err;//sometimes we don't have a nice way of handling it
      }
    })
}

拒绝让我们跳过正常的成功行为，直到我们找到一个知道如何处理它的方法。作为另一个例子，我们可能有一些函数深深地嵌套在应用程序堆栈的底部，它拒绝。这可能直到堆栈的最顶端才被处理，在那里我们可以记录它。关键是拒绝在堆栈上传播，就像同步代码中的异常一样。

一般来说，只要有可能，如果你正在努力编写一些异步代码，你应该思考“如果这是同步的，我会写什么”。从那里得到promise的等价物通常是一个相当简单的转换。

在exists方法中可以使用拒绝的promise：

function exists(filePath) {
  return stat(filePath) //where stat gets last updated time etc. of the file
    .then(function () { return true; }, function () { return false; })
}

请注意，在这种情况下，拒绝是完全预期的，只是意味着文件不存在。还请注意它是如何并行同步函数的：

function existsSync(filePath) {
  try {
    statSync(filePath);
    return true;
  } catch (ex) {
    return false;
  }
}

回到你的例子：

如果找不到用户，我通常会拒绝由findUserByEmail产生的promise。这是你完全期待有时会发生的事情，但这是正常情况下的例外，应该像处理所有其他错误一样处理。类似地，如果我正在编写一个同步函数，我会让它抛出一个异常。

有时只返回null可能很有用，但这取决于应用程序逻辑，可能不是最好的方法。