处理错误后跳过承诺链

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
     }
   })
   

解决方案1需要将模块A特定代码添加到模块B。

解决方案2解决了这个问题，但整个假拒绝方法看起来非常苛刻。

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

Answer 1

让我们谈谈控制结构。

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

• 它可以return给调用者一个值，表示它已成功完成。
• 调用者可能会throw一个错误，表示发生了异常操作。

它看起来像：

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处理程序中调用函数时，代码以两种方式流动：

• 它可以return表示成功完成的承诺或值。
• 它可以throw表示发生异常状态的错误。

它看起来像：

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");
});

承诺控制本身的模型流程

承诺是对概念排序操作本身的抽象概念。它描述了控件如何从一个语句传递给另一个语句。您可以将.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
    }
}

因此，如何继续使用其余代码只需returning。这在同步代码和带有promise的异步代码中是相同的。执行非常具体的错误处理也没问题。

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

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

好吧，即使没有立即， 是一种相当简单的方法，通过让doC进入无限循环来使doD永远不会执行：

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

所以， 可能永远不会解决承诺 - 就像其他答案所暗示的那样 - 返回一个未决的承诺。然而，这是非常差的流量控制，因为意图很难传达给消费者，并且可能很难调试。想象一下以下API：

  

moduleA_exportedFunction - 此函数发出API请求，并在数据可用时将服务作为ServiceData对象返回。否则，将程序输入无限循环。

有点混乱，不是吗:)？但是，它实际上存在于某些地方。在非常古老的API中找到以下内容并不罕见。

  

some_bad_c_api（） - 此功能会出现一个条形图，如果失败则终止进程。

那么，是什么让我们无法理解终止该API中的流程呢？

一切都与责任有关。

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

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

投掷

更好的解决方案是抛出错误并让消费者处理它。我在这里使用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.
});

所以在一行中 - 你会做你在同步代码中会做的事情，就像承诺一样。

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

Answer 2

这是一种设计的东西。通常，当模块或服务返回promise时，如果调用成功，则希望它解析，否则失败。承诺既不解决也不失败，即使你知道电话不成功，基本上也是一种无声的失败。

但是，嘿，我不知道你的模块或原因的具体细节，所以如果你想在这种情况下默默地失败，你可以通过返回一个未解决的承诺来做到这一点：

//模块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
      return q.defer().promise;
    }
  });
}

Answer 3

受到本杰明·格伦鲍姆的评论和回答的启发 - 如果我用同步代码写这个，我会让moduleA_exportedFunction返回一个shouldContinue布尔值。

所以有了承诺，它基本上会是这样的（免责声明：这是伪代码，未经测试）

// Module A

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

// Module B

moduleA_exportedFunction()
  .then(function(shouldContinue) {
    if (shouldContinue) {
      return moduleB_promiseReturningFunction().then(moduleB_anotherFunction);
    }
  })
  .fail(function(reason) {
    // Handle the reason in a general way which is ok for module B functions
    // (And anything unhandled from module A would still get caught here)
  })
  .done()
;

它确实需要模块B中的一些处理代码，但逻辑既不特定于模块A的内部也不涉及抛出和忽略假错误 - 完成任务！ ：）