javascript - 处理错误后跳过 promise 链

Question

使用 https://github.com/kriskowal/q图书馆，我想知道是否有可能做这样的事情:

// Module A

function moduleA_exportedFunction() {
  return promiseReturningService().then(function(serviceResults) {
    if (serviceResults.areGood) {
      // We can continue with the rest of the promise chain
    }
    else {
      performVerySpecificErrorHandling();
      // We want to skip the rest of the promise chain
    }
  });
}

// Module B

moduleA_exportedFunction()
  .then(moduleB_function)
  .then(moduleB_anotherFunction)
  .fail(function(reason) {
    // Handle the reason in a general way which is ok for module B functions
  })
  .done()
;

基本上，如果服务结果不好，我想处理模块 A 中的故障，使用特定于模块 A 内部的逻辑，但仍然跳过 promise 链中剩余的模块 B 函数。

跳过模块 B 函数的明显解决方案是从模块 A 中抛出错误/原因。但是，然后我需要在模块 B 中处理它。理想情况下，我想在不需要任何额外代码的情况下执行此操作模块 B。

这很可能是不可能的 :) 或者违背 Q 的一些设计原则。

在这种情况下，您会建议哪种替代方案？

我有两种方法，但都有其缺点:

1. 从模块 A 中抛出一个特定的错误并向模块 B 添加特定的处理代码:

   .fail(function(reason) {
     if (reason is specificError) {
       performVerySpecificErrorHandling();
     }
     else {
       // Handle the reason in a general way which is ok for module B functions
     }
   })
   

2. 在模块A中进行自定义的错误处理，然后在处理完错误后，抛出一个伪造的拒绝原因。在模块B中，添加一个条件来忽略假的原因:

   .fail(function(reason) {
     if (reason is fakeReason) {
       // Skip handling
     }
     else {
       // Handle the reason in a general way which is ok for module B functions
     }
   })
   

方案一需要在模块B中添加模块A的具体代码。

解决方案 2 解决了这个问题，但整个伪造拒绝方法似乎很老套。

您能推荐其他解决方案吗？

Answer 1

让我们谈谈控制构造。

在 JavaScript 中，调用函数时代码以两种方式流动。

• 它可以返回一个值给调用者，表明它成功完成。
• 它可以向调用者抛出一个错误，表明发生了异常操作。

它看起来像:

function doSomething(){ // every function ever
  if(somethingBad) throw new Error("Error operating");
  return value; // successful completion.
}

try{
  doSomething();
  console.log("Success");
} catch (e){
  console.log("Boo");
}

Promises 模拟这种完全相同的行为。

在 Promises 中，当您在 .then 处理程序中调用函数时，代码恰好以两种方式流动:

• 它可以返回一个 promise 或一个表明它成功完成的值。
• 它可以抛出一个错误，表明发生了异常状态。

它看起来像:

var doSomething = Promise.method(function(){
  if(somethingBad) throw new Error("Error operating");
  return someEventualValue(); // a direct value works here too
}); // See note, in Q you'd return Q.reject()

Promise.try(function(){ // in Q that's Q().then
  doSomething();
  console.log("Success");
}).catch(function(e){
  console.log("Boo");
});

Promises 模型控制流本身

Promise 是对排序操作 本身概念的抽象。它描述了控制如何从一个语句传递到另一个语句。您可以将 .then 视为对分号的抽象。

我们来谈谈同步代码

让我们看看同步代码在您的情况下会是什么样子。

function moduleA_exportedFunction() {
  var serviceResults = someSynchronousFunction();
    if (serviceResults.areGood) {
      // We can continue with the rest of our code
    }
    else {
      performVerySpecificErrorHandling();
      // We want to skip the rest of the chain
    }
}

因此，如何继续我们的其余代码就是简单地返回。这在同步代码和带有 promise 的异步代码中是一样的。执行非常具体的错误处理也是可以的。

我们如何跳过同步版本中的其余代码？

doA();
doB();
doC(); // make doD never execute and not throw an exception
doD();

好吧，即使不是立即，也有一种相当简单的方法可以让 doD 永远不会执行，方法是让 doC 进入无限循环:

function doC() {
    if (!results.areGood) {
      while(true){} // an infinite loop is the synchronous analogy of not continuing
                    // a promise chain.
    }
}

因此，有可能永远无法解决 promise - 就像其他答案所暗示的那样 - 返回一个未决的 promise 。然而，这是非常糟糕的流量控制，因为意图没有很好地传达给消费者，并且可能很难调试。想象一下以下 API:

moduleA_exportedFunction - this function makes an API request and returns the service as a ServiceData object if the data is available. Otherwise, it enters the program into an endless loop.

有点令人困惑，是不是 :)？但是，它确实存在于某些地方。在非常古老的 API 中发现以下内容并不少见。

some_bad_c_api() - this function foos a bar, on failure it terminates the process.

那么，到底是什么困扰着我们终止该 API 中的进程？

一切都是为了责任。

• 被调用的 API 有责任传达 API 请求是否成功。
• 来电者有责任决定在每种情况下要做什么。

在你的情况下。 ModelA 只是违反了它的责任限制，它不应该有权对程序的流程做出这样的决定。消费它的人应该做出这些决定。

throw

更好的解决方案是抛出错误并让消费者处理。我将使用 Bluebird promises在这里，因为它们不仅快了两个数量级，而且具有更现代的 API - 它们还具有更好的调试工具 - 在这种情况下 - 用于条件捕获和更好的堆栈跟踪的糖:

moduleA_exportedFunction().then(function(result){
   // this will only be reached if no error occured
   return someOtherApiCall();
}).then(function(result2){
   // this will be called if the above function returned a value that is not a 
   // rejected promise, you can keep processing here
}).catch(ApiError,function(e){
   // an error that is instanceof ApiError will reach here, you can handler all API
   // errors from the above `then`s in here. Subclass errors
}).catch(NetworkError,function(e){
   // here, let's handle network errors and not `ApiError`s, since we want to handle
   // those differently
}).then(function(){
   // here we recovered, code that went into an ApiError or NetworkError (assuming
   // those catch handlers did not throw) will reach this point.
   // Other errors will _still_ not run, we recovered successfully
}).then(function(){
   throw new Error(); // unless we explicitly add a `.catch` with no type or with 
                      // an `Error` type, no code in this chain will run anyway.
});

所以在一行中 - 你会做你会在同步代码中做的事情，就像 promises 通常的情况一样。

^{注意 Promise.method 只是 Bluebird 用于包装函数的便利函数，我只是讨厌同步投入 promise 返回 API，因为它会造成重大破坏。}