关于前端:Promise关于catch你真的了解catch的执行顺序吗

明天忽然被共事问到一个问题，以下代码怎么输入：

Promise.all([new Promise(res => res(0)), 
   new Promise((res, rej) => rej(1))
]).then(v => {console.log('then 1 ======', v)    
}).catch(e => {console.log('catch 1 ======', e)
})

Promise.all([new Promise(res => res(0)), 
   new Promise(res => res(1)),
   new Promise(res => res(2)), 
   new Promise(res => res(3))
]).then(v => {console.log('then 2 ======', v)    
}).catch(e => {console.log('catch 2 ======', e)
})

一眼看完，我果决答复了如下答案：

catch 1 ======  1
then 2 ======  [0, 1, 2, 3]

然而 … 翻了个大车，理论代码运行后果是：

then 2 ======  [0, 1, 2, 3]
catch 1 ======  1

始终以来都有个误会，认为 then 和 catch 的执行是一个二选一的过程，但这段代码颠覆了我的认知，这是为什么？它的执行过程是怎么的？Promise.all() 办法的特点是输出的所有 promise 都实现则实现，有一个回绝则回绝，所以显然不是 Promise.all() 的问题。

那么其实能够将下面的例子简化成如下代码，前面的剖析将以如下代码为例

Promise.reject().then(() => {console.log('1-1')
}).catch(() => {console.log('1-2')
})


Promise.resolve().then(() => {console.log('2-1')
}).catch(() => {console.log('2-2')
})

这段代码的执行后果是：2-1、1-2

翻了一下 MDN：catch

也就是说，catch 是 then 的语法糖，obj.catch(fn) 外部其实是调用 obj.then(undefined, fn)。

依据 Promise/A+ 标准，Promise.prototype.then(arg1, arg2) 两个参数都是可选，分为以下两种状况：

如果 promise 状态是 fullfilled，而 arg1 是 undefined，那么 arg1 就相当于 x => x
如果 promise 的状态是 rejected，而 arg2 是 undefined，那么 arg2 是一个 throw error

Promise/A+ 标准：https://promisesaplus.com/

联合下面的解释，代码的执行过程为：

1、执行同步代码，解析 Promise.reject().then(fn)，满足状况二，相当于：

Promise.reject().then(() => {console.log('1-1')
}, () => {throw Error();
}).catch(() => {console.log('1-2')
})

咱们晓得 then 办法的返回值也是一个 promise，此时假如调用 Promise.reject().then(arg1, arg2) 返回的 promise 为 p1。

留神此时推入微工作队列的是 arg2，也就是抛出谬误的回调（Promise 状态扭转后，then 中的回调才会被推入微工作队列）。之后 p1 又调用了 catch，因为此时 p1 状态还没有被解决（p1 处于 pending 状态），前面的 catch 设置的回调不会执行，而 p1 的状态要等到解决微工作队列时才会被解决。

假如微工作队列为一个数组，那么此时微工作队列中应该为：

[() => {throw Error()
}]

2、继续执行同步代码，解析 Promise.resolve().then(fn)，Promise 状态为 fulfilled，then 中的回调 fn 被失常推入微工作队列。

Promise.resolve().then(() => {console.log('2-1')
}).catch(() => {console.log('2-2')
})

此时微工作队列中应该为：

[() => {throw Error()
},() => {console.log('2-1')
}]

3、同步代码执行完了，清空微工作队列中的工作：

取出第一个工作执行，抛出谬误，相当于将 p1 的状态设置为 rejected，那么此时前面的 catch 中的回调函数也被推入微工作队列

此时微工作队列为：

[() => {console.log('2-1')
},() => {console.log('1-2')
}]

取出第二个工作执行，打印 2 -1

此时微工作队列为：

[() => {console.log('1-2')
}]

取出第三个工作执行，打印 1 -2

此时微工作队列为：微工作队列清空。

[]

这个问题的要害就在于 catch 外部调用的还是 obj.then(undefined, arg2)，如果前一个 promise 的状态是 rejected，并且 then 中第二个参数 arg2 是 undefined，那么 arg2 是一个 throw error，因而状态会顺延到 Event Loop 下一次 Tick。

再看上面的例子：

Promise.reject().then(() => {console.log('1-1')
}).catch(() => {console.log('1-2')
  throw Error()}).then(() => {console.log('1-3')
}).catch(() => {console.log('1-4')
})

Promise.resolve().then(() => {console.log('2-1')
}).catch(() => {console.log('2-2')
})

调用 catch 办法在没有设置返回值的状况下默认也会返回一个状态为 fulfilled 的 promise，失常状况下会走前面设置的 then 回调，但因为这里咱们在 catch 中抛出了新的谬误，所以又回到了后面呈现的问题——前面的 then 中的 arg2 为 throw error，因而状态再次发生顺延。

输入程序为：2-1、1-2、1-4

当然，如果要按结尾翻车的答案程序执行，在确定后面的 Promise 状态为 rejected 时，不接 then，间接调用 catch 即可。

Promise.reject().catch(() => {console.log('1-2')
})

Promise.resolve().then(() => {console.log('2-1')
}).catch(() => {console.log('2-2')
})

输入程序为：1-2、2-1

看到这我想你曾经明确大略是怎么回事了，总之，遇到问题稳住不要慌，文档 + 源码浏览能解决百分之八十以上的问题，肯定要多思考，多了解，加油打工人~

Promise 中 then 和 catch 的执行过程

MDN：Promise.prototype.catch()

本文由博客一文多发平台 OpenWrite 公布！

关于前端:Promise关于catch你真的了解catch的执行顺序吗

一、问题

二、执行过程拆解

三、小结

四、参考