成熟的产品都有较高的稳定性要求，仅前端就要做大量监控、谬误上报，后端更是如此，一个未思考的异样可能导致数据谬误、服务雪崩、内存溢出等等问题，轻则每天焦头烂额的解决异样，重则引发线上故障。
假如代码逻辑没有谬误，那么剩下的就是异样谬误了。
因为任何服务、代码都可能存在内部调用，只有内部调用存在不确定性，代码就可能出现异常，所以捕捉异样是一个十分重要的基本功。
所以本周就精读 How to avoid uncaught async errors in Javascript 这篇文章，看看 JS 如何捕捉异步异样谬误。
概述
之所以要关注异步异样，是因为捕捉同步异样非常简单：
try { ;(() => { throw new Error('err') })()} catch (e) { console.log(e) // caught}但异步谬误却无奈被间接捕捉，这不太直观：
try { ;(async () => { throw new Error('err') // uncaught })()} catch (e) { console.log(e)}起因是异步代码并不在 try catch 上下文中执行，惟一的同步逻辑只有创立一个异步函数，所以异步函数内的谬误无奈被捕捉。
要捕捉 async 函数内的异样，能够调用 .catch，因为 async 函数返回一个 Promise：
;(async () => { throw new Error('err')})().catch((e) => { console.log(e) // caught})当然也能够在函数体内间接用 try catch：
;(async () => { try { throw new Error('err') } catch (e) { console.log(e) // caught }})()相似的，如果在循环体里捕捉异样，则要应用 Promise.all：
try { await Promise.all( [1, 2, 3].map(async () => { throw new Error('err') }) )} catch (e) { console.log(e) // caught}也就是说 await 润饰的 Promise 内抛出的异样，能够被 try catch 捕捉。
但不是说写了 await 就肯定能捕捉到异样，一种状况是 Promise 内再蕴含一个异步：
new Promise(() => { setTimeout(() => { throw new Error('err') // uncaught }, 0)}).catch((e) => { console.log(e)})这个状况要用 reject 形式抛出异样能力被捕捉：
new Promise((res, rej) => { setTimeout(() => { rej('err') // caught }, 0)}).catch((e) => { console.log(e)})另一种状况是，这个 await 没有被执行到：
const wait = (ms) => new Promise((res) => setTimeout(res, ms));(async () => { try { const p1 = wait(3000).then(() => { throw new Error('err') }) // uncaught await wait(2000).then(() => { throw new Error('err2') }) // caught await p1 } catch (e) { console.log(e) }})()p1 期待 3s 后抛出异样，但因为 2s 后抛出了 err2 异样，中断了代码执行，所以 await p1 不会被执行到，导致这个异样不会被 catch 住。
而且有意思的是，如果换一个场景，提前执行了 p1，等 1s 后再 await p1，那异样就从无奈捕捉变成能够捕捉了，这样浏览器会怎么解决？
const wait = (ms) => new Promise((res) => setTimeout(res, ms));(async () => { try { const p1 = wait(1000).then(() => { throw new Error('err') }) await wait(2000) await p1 } catch (e) { console.log(e) }})()论断是浏览器 1s 后会抛出一个未捕捉异样，但再过 1s 这个未捕捉异样就隐没了，变成了捕捉的异样。
这个行为很奇怪，当程序简单时很难排查，因为并行的 Promise 倡议用 Promise.all 解决：
await Promise.all([ wait(1000).then(() => { throw new Error('err') }), // p1 wait(2000),])另外 Promise 的谬误会随着 Promise 链传递，因而倡议把 Promise 内屡次异步行为改写为多条链的模式，在最初 catch 住谬误。
还是之前的例子，Promise 无奈捕捉外部的异步谬误：
new Promise((res, rej) => { setTimeout(() => { throw Error('err') }, 1000) // 1}).catch((error) => { console.log(error)})但如果写成 Promise Chain，就能够捕捉了：
new Promise((res, rej) => { setTimeout(res, 1000) // 1}) .then((res, rej) => { throw Error('err') }) .catch((error) => { console.log(error) })起因是，用 Promise Chain 代替了外部屡次异步嵌套，这样多个异步行为会被拆解为对应 Promise Chain 的同步行为，Promise 就能够捕捉啦。
最初，DOM 事件监听内抛出的谬误都无奈被捕捉：
document.querySelector('button').addEventListener('click', async () => { throw new Error('err') // uncaught})同步也一样：
document.querySelector('button').addEventListener('click', () => { throw new Error('err') // uncaught})只能通过函数体内 try catch 来捕捉。
精读
咱们开篇提到了要监控所有异样，仅通过 try catch、then 捕捉同步、异步谬误还是不够的，因为这些是部分谬误捕捉伎俩，当咱们无奈保障所有代码都解决了异样时，须要进行全局异样监控，个别有两种办法：
window.addEventListener('error')window.addEventListener('unhandledrejection')
error 能够监听所有同步、异步的运行时谬误，但无奈监听语法、接口、资源加载谬误。而 unhandledrejection 能够监听到 Promise 中抛出的，未被 .catch 捕捉的谬误。
在具体的前端框架中，也能够通过框架提供的谬误监听计划解决局部问题，比方 React 的 Error Boundaries、Vue 的 error handler，一个是 UI 组件级别的，一个是全局的。
回过头来看，自身 js 提供的 try catch 谬误捕捉是十分无效的，之所以会遇到无奈捕捉谬误的常常，大多是因为异步导致的。
然而大部分异步谬误，都能够通过 await 的形式解决，咱们惟一要留神的是，await 仅反对一层，或者说一条链的谬误监听，比方这个例子是能够监听到谬误的：
try { await func1()} catch (err) { // caught}async function func1() { await func2()}async function func2() { throw Error('error')}也就是说，只有这一条链内都被 await 住了，那么最外层的 try catch 就能捕捉异步谬误。但如果有一层异步又脱离了 await，那么就无奈捕捉了：
async function func2() { setTimeout(() => { throw Error('error') // uncaught })}针对这个问题，原文也提供了例如 Promise.all、链式 Promise、.catch 等办法解决，因而只有编写代码时留神对异步的解决，就能够用 try catch 捕捉这些异步谬误。
总结
对于异步谬误的解决，如果还有其它未思考到的状况，欢送留言补充。
探讨地址是：精读《捕捉所有异步 error》· Issue #350 · dt-fe/weekly
如果你想参加探讨，请 点击这里，每周都有新的主题，周末或周一公布。前端精读 - 帮你筛选靠谱的内容。
关注 前端精读微信公众号
<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
版权申明：自在转载-非商用-非衍生-放弃署名（创意共享 3.0 许可证）