处理错误后跳过承诺链 [英] Skipping promise chain after handling error

查看:39
本文介绍了处理错误后跳过承诺链的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

使用 https://github.com/kriskowal/q 库,我想知道是否有可能做点什么像这样:

Using the https://github.com/kriskowal/q library, I'm wondering if it's possible to do something like this:

// 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中的故障,但仍然跳过承诺链中其余的模块B功能.

Basically if the service results are bad, I'd like to handle the failure in module A, using logic that is specific to the internals of module A, but still skip the remaining module B functions in the promise chain.

跳过模块B功能的明显解决方案是从模块A抛出错误/原因.但是,我将需要在模块B中处理该错误/原因.理想情况下,我希望这样做无需在模块中添加任何额外的代码.B模块.

The obvious solution for skipping module B functions is to throw an error/reason from module A. However, then I would need to handle that in module B. And ideally I'd like to do it without needing any extra code in module B for that.

这很可能是不可能的:)或违反Q的某些设计原则.

Which may very well be impossible :) Or against some design principles of Q.

在哪种情况下,您会建议什么样的替代方案?

In which case, what kind of alternatives would you suggest?

我有两种方法,但都有缺点:

I have two approaches in mind, but both have their disadvantages:

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

  1. Throw a specific error from module A and add specific handling code to module B:

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

  • 在模块A中执行自定义错误处理,然后在处理错误之后,抛出伪造的拒绝原因.在模块B中,添加条件以忽略虚假原因:

  • Perform the custom error handling in module A, then after handling the error, throw a fake rejection reason. In module B, add a condition to ignore the fake reason:

    .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.

    Solution 1 requires adding module A specific code to module B.

    解决方案2可以解决此问题,但是整个假拒绝方法似乎非常棘手.

    Solution 2 solves this, but the whole fake rejection approach seems very hackish.

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

    Can you recommend other solutions?

    推荐答案

    受本杰明·格鲁恩鲍姆(Benjamin Gruenbaum)的评论和答案的启发-如果我使用同步代码编写此代码,则我将使 moduleA_exportedFunction 返回一个应该继续布尔值.

    Inspired by Benjamin Gruenbaum's comments and answer - if I was writing this in synchronous code, I would make moduleA_exportedFunction return a shouldContinue boolean.

    因此,有了承诺,基本上就是这样(免责声明:这是伪代码式的,未经测试)

    So with promises, it would basically be something like this (disclaimer: this is psuedo-code-ish and untested)

    // 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的内部,也不涉及抛出和忽略虚假错误-已完成任务!:)

    It does require some handling code in module B, but the logic is neither specific to module A's internals nor does it involve throwing and ignoring fake errors - mission accomplished! :)

    这篇关于处理错误后跳过承诺链的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

    查看全文
    登录 关闭
    扫码关注1秒登录
    发送“验证码”获取 | 15天全站免登陆