如何避免在JavaScript异步队列try catch中遇到的问题？
- 内容介绍
- 文章标签
- 相关推荐
本文共计1697个文字，预计阅读时间需要7分钟。
目录
一、前言
二、主要讲解的异步队列方法
2.1 setTimeout 2.1.1 问题表现 2.1.2 问题原因 2.2 Promise 2.3 callback 2.4 Async/await目录
- 一、前言
- 二、主要讲的异步队列方法
- 2.1 setTimeout
- 2.1.1 问题表现
- 2.1.2 问题原因
- 2.2 Promise
- 2.3 callback
- 2.4 Async await
一、前言
我们在写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内容请搜索自由互联以前的文章或继续浏览下面的相关文章希望大家以后多多支持自由互联！
本文共计1697个文字，预计阅读时间需要7分钟。
目录
一、前言
二、主要讲解的异步队列方法
2.1 setTimeout 2.1.1 问题表现 2.1.2 问题原因 2.2 Promise 2.3 callback 2.4 Async/await目录
- 一、前言
- 二、主要讲的异步队列方法
- 2.1 setTimeout
- 2.1.1 问题表现
- 2.1.2 问题原因
- 2.2 Promise
- 2.3 callback
- 2.4 Async await
一、前言
我们在写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内容请搜索自由互联以前的文章或继续浏览下面的相关文章希望大家以后多多支持自由互联！