一、前言
我们在写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 啦。
到此这篇关于JavaScript异步队列进行try catch时的问题解决的文章就介绍到这了,更多相关JS try catch内容请搜索Devmax以前的文章或继续浏览下面的相关文章希望大家以后多多支持Devmax！