检测Angular JavaScript promise链中是否存在下一个处理程序

发布时间：2020-12-17 07:00:46 所属栏目：安全来源：网络整理

导读：给出以下两个$资源示例： var exampleOne = $resource('/path').save(objectOne);exampleOne.$promise.then(function (success) {},function (error) {});var exampleTwo = $resource('/path').save(objectTwo);exampleTwo.$promise.then(function (success)

给出以下两个$资源示例：

var exampleOne = $resource('/path').save(objectOne);
exampleOne.$promise.then(function (success) {},function (error) {});

var exampleTwo = $resource('/path').save(objectTwo);
exampleTwo.$promise.then(function (success) {});

[注意：示例二不包含错误处理程序]

以及位于所有$http请求下方的拦截??器：

var interceptor = ['$location','$q',function ($location,$q) {
   function error(response) {
       if (response.status === 400) {
           return $q.reject(response);
       }
       else {
           $location.path('/error/page');
       }
       return $q.reject(response);
   }

   return {
       'responseError': error
   };
}

$httpProvider.interceptors.push(interceptor);

当示例资源$promise.then()不包含错误回调时,如何使拦截器不被拒绝？如果回调存在,例如exampleOne,那么我希望拒绝,但如果不是如例2那么我希望重定向到错误页面,从而将条件更改为：

if (response.status === 400 && $q.unresolvedPromises.doIndeedExist()) { ...

为什么？因为我的项目中只有一些情况要求以用户友好的方式处理400,所以我想消除许多重复的错误回调或者必须在拦截器中放置一个不常见的情况列表.我希望拦截器能够根据promise链中另一个处理程序的存在来决定.

解决方法

简单地说这是不可能的,你无法检测到某人是否会在将来的某个时刻附加一个处理程序,就像你无法判断你何时抛出一个函数一样,它是否会被外部捕获.但是,你想要做的就是完成.

这不是一个’noob问题’,它是非常基础的：

function foo()
    throw new Error(); // I want to know if whoever is calling `foo`
                       // handles this error
 }

首先,你可以做什么

简单地说就是第一种情况：

exampleOne.$promise.then(function (success) {},function (error) {});

你得到的是一个永远满足的承诺.但是,在第二种情况下,承诺可能会被拒绝.使用拒绝处理程序处理拒绝就像实际代码中的一个问题 – 一旦处理它就不再被拒绝.

就个人而言,我不会在这里使用拦截器,而是使用资源使用模式,因为意图更清晰,你可以将它包装在一个函数中,因此它不需要范围但我更喜欢这个想法.这就是我要做的

attempt(function(){
    return $resource('/path').save(objectTwo).$promise.
           then(function (success) {});
});

function attempt(fn){
    var res = fn();
    res.catch(function(err){
        // figure out what conditions you want here
        // if the promise is rejected. In your case check for http errors
        showModalScreen();
    }
    return res; // for chaining,catch handlers can still be added in the future,so
                // this only detects `catch` on the function passed directly so 
                // we keep composability
}

现在,这是一个无法完成的简短证明

让我们证明这很有趣.

假设我们给出了一个程序M的代码,我们创建了一个新的promise p,并用M返回p.catch(function(){})替换M中M和throw语句中的每个return语句,并添加一个返回p.catch (function(){}),现在只有当运行M终止时,处理程序才会被添加到p中.所以简而言之 – 给定代码M我们已经构建了一种方法来查看它是否基于对查找catch是否附加到p的问题的解决方案的存在而停止 – 所以这个问题至少和the halting problem一样难.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!