异步队列进行try catch时的问题

1,577 阅读5分钟

一、前言

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

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

想一下项目中用到的方式,或者jquery的ajax方式,一般都会有catch、fail之类的回调方法供我们对错误结果进行处理。 那么现在讨论的话题是能不能使用try catch进行处理。

为什么写这篇文章? 是因为我在写 10分钟了解express和koa中间件机制和错误处理机制 的时候,举例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 问题原因

好了,我们把这个疑问分析一下吧。其实,这里的根本原因还是刚开始提到的事件循环。 事件循环不是空空的一句表述、一个概念,而是在代码中实实在在存在的。

具体事件循环的相关知识,可以看下我很早前写的# 从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 啦。

简单的写了这么多,对一些机制没有太深入的去谈, 大家有兴趣可以先自行向下深挖一下。 或者评论留言,大家一起研究~~