JavaScript异步队列中try-catch捕获异常的机制与限制

一、前言

在JavaScript开发中，经常需要发起异步接口请求，或利用setTimeout、Promise等机制执行任务，随后让同步代码继续向下执行。待特定时间节点到达或数据请求成功后，再通过eventloop机制进行回调处理。这种非阻塞特性是JavaScript的核心优势之一。

然而，异步队列在执行过程中难免出现异常。此时，如何正确进行错误处理便成为开发中的关键问题。

回顾项目实践或jQuery的ajax调用，通常都会提供catch、fail等回调方法用于处理错误结果。本文探讨的核心问题是：能否直接使用try catch来统一处理这些异步错误？

撰写本文的初衷，源于在讲解JavaScript setTimeout与事件循环机制（event-loop）时，以Express异步错误获取为例引发的思考。鉴于该问题的重要性与复杂性，值得单独撰写一篇详尽且清晰的文章进行阐述。

接下来进入正文部分。

二、主要涉及的异步队列方法

2.1 setTimeout

此处提到的setTimeout泛指一类宏任务，包括setTimeout、setInterval等。关键在于：这些异步操作能否被外层的try-catch捕获？

2.1.1 问题表现

    try{
        setTimeout(() => {
            let a = c;
        }, 100)
    } catch(e) {
        console.log('能获取到错误么？？', e);
    }

实验结果表明，外层try-catch无法获取异步代码中的错误，程序会直接抛出异常。这可能导致页面崩溃，或在Node.js环境中导致整个服务挂掉。原本旨在增强程序健壮性的尝试，反而成为了无用功。

既然外层无法捕获，能否在setTimeout内部先使用try-catch捕获错误，再将其抛出传递到外部？我们进行如下分析：

    try{
        setTimeout(() => {
            try {
                let a = c;
            } catch(e) {
                throw new Error('some variable is not defined');
            }
        }, 100)
    } catch(e) {
        console.log('能获取到错误么？？', e);
    }

遗憾的是，这种思路同样行不通。外边也catch不到。

2.1.2 问题原因

让我们深入分析这一现象的根本原因。核心在于前文提到的事件循环概念。事件循环并非抽象的理论，而是代码运行中实实在在存在的机制。

关于事件循环的详细信息，可参考笔者早期撰写的《JavaScript的setTimeout与事件循环机制event-loop》一文。

回到本例，最外层的try-catch包裹在一个task中。这是JavaScript文件的同步主任务，代码从上至下执行至此。随后，内部的setTimeout被推入任务队列（任务队列），该队列由V8引擎在内存中管理。主任务继续向下执行直至结束。

当setTimeout设定的时间到达，且任务队列为空时，该setTimeout的代码会被推入执行栈（执行栈）开始执行。若执行到报错代码，即let a = c（let a = c），由于变量c未定义，程序将抛出错误。

问题的本质在于，这个错误发生时的执行栈与最外层的try-catch并不相同。当内部异步代码执行时，外层的同步任务早已执行完毕，两者的上下文（context）已完全不同。

因此，页面会直接报错，甚至导致程序崩溃。

2.2 Promise

我们知道，Promise也是一种异步处理过程，它对应事件循环中的微任务（微任务）。因此，Promise与上述setTimeout存在相同的问题。

举例如下：

    try {
        new Promise((resolve, reject) => {
            reject('promise error');
        })
    } catch(e) {
        console.log('异步错误，能catch到么？？', e);
    }

根据上述分析，大家可以推导出的结果是：也catch不到。

其原因与setTimeout的情况一致，即执行栈上下文已经不同。

针对Promise，ECMA官方提供了catch方法。通过catch可以获取错误并阻止程序崩溃。但具有发散思维的开发者可能会问：既然内部用catch接住了错误，是否就能让外层的catch捕获到呢？我们尝试一下：

    try {
        new Promise((resolve, reject) => {
            reject('promise error');
        }).catch(e => {
            throw new Error(e);
        })
    } catch(e) {
        console.log('异步错误，能catch到么？？', e);
    }

结果是不行。通过上述详细的示例与逻辑推导，相信大家对这一机制已有了深入理解。

2.3 callback

基于前面的分析，大家可能会产生一种误解：只要是callback形式，try-catch就永远无法捕获。这种观点是错误的，我们通过一个例子来证明。

    function Fn(cb) {
        console.log('callback执行了');
        cb();
    }

    try {
        const cb = () => {
            throw new Error('callback执行错误');
        }
        Fn(cb);
    } catch(e) {
        console.log('能够catch住么???')
    }

这其实是一个“烟雾弹”，旨在检验大家对事件循环相关机制的理解是否透彻。

2.4 Async await

在现代项目中，开发者越来越倾向于使用Async await这对ES7标准中的API。因为它们的使用体验极佳。那么，通过异步等待的方式，能否使用try-catch成功捕获错误？

我们通过一个示例进行验证：

const asyncFn = () => {
    return new Promise((resolve, reject) => {
        setTimeout(() => {
            reject('asyncFn执行时出现错误了')
        }, 100);
    })
}
const executedFn = async () => {
    try{
        await asyncFn();
    }catch(e) {
        console.log('拦截到错误..', e);
    }
}

运行代码后发现：catch到了!。

asyncFn内部确实包含Promise，为什么外层的try-catch能够捕获到呢？这是否与前述分析矛盾？其实并不矛盾，请看如下分析：

async-await 是使用生成器、promise 和协程实现的,wait操作符还存储返回事件循环之前的执行上下文，以便允许promise操作继续进行。当内部通知解决等待的承诺时，它会在继续之前恢复执行上下文。。因此，只要能够回到最外层的上下文，就可以使用try-catch进行捕获。

至此，关于JavaScript异步队列中try-catch问题的探讨结束。如需了解更多JS try-catch相关内容，欢迎搜索本站往期文章或继续阅读后续文章。希望大家多多支持本站！