JS try catch

一、前言

我们在写js的时候，经常的会遇到需要异步去请求接口，或者通过setTimeout或Promise去做什么事， 然后让同步进程继续向下走， 当到某个时间节点的时候或者数据请求成功的时候在通过eventloop的方式回调执行。这本身是js的特点和优势。

但是，异步队列执行也存在错误的情况，这时，对于怎么进行错误处理，就成了我们的重点。

想一下项目中用到的方式，或者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);
    }

结果是不能获取到，程序直接报错了， 那么出现的后果可能就是整个页面挂了，或者在node中，整个服务挂了。 我们的初心是想让程序更加健壮，但却做了无用功。

那么我们在想，既然在setTimeout 外边无法获取，那么能不能在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中，我们定义它为我们js文件的同步主任务，从上到下执行到这里了， 然后，会把里面的setTimeout推到一个任务队列中， 这个队列是存储在内存中的，由V8来管理。然后主task就继续向下执行， 一直到结束。

当该setTimeout时间到了，且没有其它的task执行了， 那么，就将这个setTimeout的代码推入执行栈开始执行。 当执行到错误代码的时候，也就是这个 let a = c, 因为c未定义，所以就会报错。

但问题的本质是，这个错误跟最外层的try catch并不在一个执行栈中，当里面执行的时候，外边的这个task早已执行完， 他们的context(上下文)已经完全不同了。

所以，页面会直接报错，甚至程序崩溃。

2.2 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，就是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的，为什么外边就能catch到了呢？ 是不是跟上面讲的矛盾了呢？ 其实并没有。 看我分析一下：

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