什么时候.then(成功,失败)被认为是承诺的反模式? [英] When is .then(success, fail) considered an antipattern for promises?

查看:262
本文介绍了什么时候.then(成功,失败)被认为是承诺的反模式?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我看了(推荐阅读!)。

  // some_promise_call()。then(logger.log).catch(logger.log)
try {
var results = some_call();
logger.log(results);
} catch(e){
logger.log(e);
}

catch 记录器还将处理成功记录器调用中的异常。



差异太大了。


我不太明白它对try和catch的解释


参数是通常你想要捕获错误在处理的每一步,你不应该在链中使用它。期望您只有一个处理所有错误的最终处理程序 - 而当您使用反模式时,某些后回调中的错误不会被处理。



但是,这种模式实际上非常有用:当您想要处理恰好在此步骤中发生的错误,并且您希望在没有错误发生时执行完全不同的 - 即错误无法恢复时。 请注意这是分支您的控制流程。当然,这有时是需要的。







以下内容有什么问题?

  some_promise_call()
.then(function(res){logger.log(res)},function(err){ logger.log(错误)})


你必须重复你的回调。你想要

  some_promise_call()
.catch(function(e){
return e; / /它没关系,我们只需记录它
})
.done(函数(res){
logger.log(res);
});

你也可以考虑使用 .finally()


I had a look at the bluebird promise FAQ, in which it mentions that .then(success, fail) is an antipattern. I don't quite understand its explanation as for the try and catch. What's wrong with this the following?

some_promise_call()
.then(function(res) { logger.log(res) }, function(err) { logger.log(err) })

It seems that the example is suggesting the following as the correctly way.

some_promise_call()
.then(function(res) { logger.log(res) })
.catch(function(err) { logger.log(err) })

What's the difference?

解决方案

What's the difference?

The .then() call will return a promise that will be rejected in case the callback throws an error. This means, when your success logger fails, the error would be passed to the following .catch() callback, but not to the fail callback that goes alongside with success.

Here's a control flow diagram:

To express it in synchronous code:

// some_promise_call().then(logger.log, logger.log)
then: {
    try {
        var results = some_call();
    } catch(e) {
        logger.log(e);
        break then;
    } // else
        logger.log(results);
}

The second log (which is like the first argument to .then()) will only be executed in case that no exception happened. The labelled block and the break statement feel a bit odd, this is actually what python has try-except-else for (recommended reading!).

// some_promise_call().then(logger.log).catch(logger.log)
try {
    var results = some_call();
    logger.log(results);
} catch(e) {
    logger.log(e);
}

The catch logger will also handle exceptions from the success logger call.

So much for the difference.

I don't quite understand its explanation as for the try and catch

The argument is that usually you want to catch errors in every step of the processing, and that you shouldn't use it in chains. The expectation is that you only have one final handler which handles all errors - while, when you use the "antipattern", errors in some of the then-callbacks are not handled.

However, this pattern is actually very useful: When you want to handle errors that happened in exactly this step, and you want to do something entirely different when no error happened - i.e. when the error is unrecoverable. Be aware that this is branching your control flow. Of course, this is sometimes desired.


What's wrong with this the following?

some_promise_call()
.then(function(res) { logger.log(res) }, function(err) { logger.log(err) })

That you had to repeat your callback. You rather want

some_promise_call()
   .catch(function(e) {
       return e; // it's OK, we'll just log it
   })
   .done(function(res) {
       logger.log(res);
   });

You also might consider using .finally() for this.

这篇关于什么时候.then(成功,失败)被认为是承诺的反模式?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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