异步编程终极方案？不加try catch的async/await到底有多危险

在异步编程这个范畴之内，Promise以及async/await二者到底该如何抉择，始终都是开发者们热烈讨论的一个话题。身为长期对技术演进保持关注的技术观察者，我觉得async/await所带来的代码可读性方面的提升，的确是值得予以肯定的，然而错误处理机制存在的不统一状况，正逐渐变成影响代码质量的关键要素。在今天，我们就要针对这个看上去似乎简单，实际上却暗藏着玄机的话题展开深入探讨。

异步编程的现状

当下JavaScript生态里面，Promise以及async/await已然变成处理异步操作的主要办法，依据2023年StackOverflow开发者调查，超出78%的JavaScript项目在运用async/await语法，这种语法糖使得异步代码的编写更为直观，减少了回调地狱所带来的维护成本。

于实际开发里头，async/await的优势显著突出，它让代码执行流程更契合人类的线性思维习惯，规避了Promise链式调用里频繁的then方法嵌套，诸多团队在代码规范中明确规定要运用async/await去处理复杂的异步逻辑。

function getUserInfo () {
    return new Promise((resolve, reject) => {
        setTimeout(() => {
            reject('请求出错了哦')
        }, 1000)
    })
}
async function logined () {
    try {
        let userInfo = await getUserInfo()
        // 如果上面出错了，这里就不会执行了
        let pageInfo = await getPageInfo(userInfo?.userId)
    } catch(e) {
        console.warn('抓到一个错误:', e)
    }
}
logined()

错误处理的重要性

于异步操作里头，错误处理跟应用的稳定性直接关联着。未被捕获的Promise拒绝情形有可能致使整个应用出现崩溃状况。按照Node.js官方所统计的情况来看，大概35%的生产环境错误乃源自没有妥善处理好的异步异常 。

尤其是在网络请求、文件操作这类关键业务场景当中，完善的错误处理机制能够切实有效地防止雪崩效应。2022年，GitHub有一项研究表明，那些采用系统化错误处理的项目，其在生产环境之中的事故率相较于其他项目而言低42% 。

function getUserInfo () {
    return new Promise((resolve, reject) => {
        setTimeout(() => {
            reject('请求出错了哦')
        }, 1000)
    })
}
async function logined () {
    let userInfo = await getUserInfo().catch(e => console.warn('抓到一个错误:', e))
    // 注意：这里即使出错了也会继续执行！
    if (!userInfo) return // 所以得手动检查一下
    let pageInfo = await getPageInfo(userInfo?.userId)
}
logined()

try-catch的传统方案

可供直接捕获错误的方式之中，传统的try-catch块是最为直接的。当await表达式出现异常状况时，执行会马上跳转至catch块，对错误进行处理，此机制与同步代码在错误处理方面毫无差异。在那些需要立刻中断流程的场景里面，这种方案的可靠性极其突出。

然而，try-catch那种繁杂冗长的语法当真无疑是增加了代码的行数，于处理多个异步操作之际，嵌套着的try-catch块会对代码的可读性造成影响，这正是致使部分开发者对其望而却步的缘由所在。

function getUserInfo () {
    return new Promise((resolve, reject) => {
        setTimeout(() => {
            reject('请求出错了哦')
        }, 1000)
    })
}
async function logined () {
    let userInfo = await getUserInfo().catch(e => {
        console.warn('抓到一个错误:', e)
        return Promise.reject(e) // 这里再扔出去一次
    })
    // 这样就会停在这里了
    let pageInfo = await getPageInfo(userInfo?.userId)
}
logined()

catch方法的替代方案

将. catch()直接接续在await表达式之后，是另外一种较为常见的做法，这种方式源自Promise的原生方法，它能够让开发者以更具函数式的形式去处理错误。鉴于在不需要即刻中断执行的情景之下，该方案会显得更为灵活一些 。

这种做法存在缺点，那就是程序会持续执行后续代码，开发者得手动去检查数据状态。一旦忘记做这个空值检查，就极有可能引发更为隐蔽的运行时错误，对不对？

封装统一的错误处理

实际项目里，借助封装请求库去达成统一错误处理是业界所推荐的最佳实践方式，像在axios拦截器当中全局处理HTTP状态码错误行为一样，或者是业务层去封装通用错误处理逻辑举动，此种做法就会显著减少重复性代码 。

在2023的技术分享里，有一家知名的互联网公司表明，他们借助统一错误封装，把错误处理代码量降低了65%，不仅确保错处处理的完整性，还维持代码的简洁性。

let userInfo = await getUserInfo().catch(e => console.warn(e))
if (!userInfo) return // 记得检查一下是不是空的

实践建议与总结

站在工程实践这样子的角度来看呢，建议依据具体的场景去挑选合适的错误处理方案哦。针对于关键业务流程而言呀，try-catch能够给出最为可靠的保障哟；然而对于非核心操作来讲呢，.catch()或许会更具备灵活性一些呢。重要之处在于要在团队之内构建起统一的规范呀。

出于对代码可维护性的考量，提议于项目起始阶段设定明晰的错误处理规范，涵盖确定哪些异常需即刻终止执行，哪些能够进行降级处置，以及怎样记录错误日志等内容，而这些规范会对项目长期的可维护性产生直接影响。

try {
    let userInfo = await getUserInfo()
    let pageInfo = await getPageInfo(userInfo?.userId)
} catch(e) {
    console.warn(e)
}

于您的项目里头，您更为偏向采用哪一种错误处理方案呢？欢迎在评论区域分享您的实践经历，要是觉着本文对您有着帮助，请毫不吝惜地进行点赞给予支持！