前言
如果你对同步任务/异步任务/回到地狱/promise概念/async-await的作用不是很了解的话，或许需要看一下以下简单的介绍。
如果都了解则可以直接点击侧边栏跳到下面看await无法处理错误信息的解决方案。
同步和异步
javascript是一个单线程的语言。因为是单线程。所以这直接导致了线程阻塞的问题，在前一个任务完成以前，后面所有的任务都无法执行。因为这个问题。所以javascript有了异步任务的概念。
javascript把其中的任务分为两部分，一种是同步任务，一种是异步任务，一些可能造成阻塞的任务归为异步任务，并将异步任务放到所有的同步任务之后去执行，以解决阻塞问题。
常见的异步任务有
settimeout/setIntervalPromise的then函数XMLHttpRequest（http请求也就是ajax）
异步任务解决了执行堵塞的问题，同时也存在一些问题（如下）。
异步任务所存在的问题
异步任务需要回调来处理任务结束以后的一些动作。在一些特殊场景下，有些异步任务需要依赖于其他异步任务的回调。这就需要将需要依赖的异步任务写到被依赖的异步任务的回调中。
这是一种解决依赖异步依赖的方案，虽然可行，但不可读。 总会出现依赖层级较多的情况，大量的层级会让这个功能变得非常晦涩。可读性极差。如下👇
虽然一般开发中很少会出现这种嵌套7层的异步任务。但嵌套3，4层还是相对常见的。多层的嵌套配合本身存在的逻辑。对代码的阅读非常不友好。前端工程师们为了解决这个问题。在ES6中推出了Promise。
Promise如何解决回调地狱
Promise提供resolve和reject两个函数来代表异步任务的成功和失败。最关键的一点是Promise提供了.then()和.catch()函数，.then()函数负责处理异步任务成功后的动作，.catch()负责处理异步任务失败后的动作。
他们在一定程度上优化了回调地狱
Promise还可以进行链式调用
虽然Promise对于地狱回调有所改善。但他依然有着一定的嵌套结构存在。有没有什么方案可以彻底脱离嵌套结构？
有
es6后来又推出了async/await(Promise的语法糖)。
async/await，回调地狱的最终方案
async/await完全解决了回调嵌套的问题。实现了以看似同步的代码，完成异步的需求。
async右边的函数会返回一个Promise对象。如图👇
await是等待一个async函数执行完毕，并提取Promise中的值。👇
这样，我们就摆脱了嵌套结构的问题。现在我们来看下整套一起使用。
async/await错误处理方案
async/await作为promise的语法糖。它彻底解决了回调地狱的问题，但也存在一个问题。相对于Promise的链式调用。async/await无法捕获错误。普通的Promise是通过.catch()和reject()配合来进行错误程序处理。但是async/await并没有在语法内部提供错误处理。
这就导致了如果异步请求错误，我们无法做出相应补救措施而且错误信息会在控制台打印。
现在我们常规await的处理方案有以下几种。
第一种，手动添加啊try{}catch{}进行捕获
我们可以通过手动给async函数内部添加*try{}catch{}*来进行错误捕获，如此，就可以避免错误在控制台打印和阻塞代码的运行。如下
这种做法的弊端是:需要捕获错误的async多的话。每一个都写下去，就比较麻烦和不可读了。
第二种，使用await-to-js库
网上总有大牛帮我们解决这些问题。await-to-js是一个帮助我们解决异步错误处理的库，知名度较高，到目前有2.7k的⭐。
这是一种比较简单的处理方式
源码 ---ts版本
ts版本的源码可能不便于阅读，以下是我翻译成js版本的源码 ，并附加注解
最后
相较于自己使用try和catch进行捕获，我更喜欢使用await-to-js这个库，简单方便，而且贴近hooks的写法让我觉得亲切。
是否有必要给每一个请求都加上一个错误捕获？我想是不需要的。我们需要知道，错误捕获并不是无偿的。在很多情况下我们并不需要去做这种特殊的处理，比如获取分页数据等。一般情况，只需要给一些可能会出现问题的async/await做这个处理即可。
总结
捕获async和await的方法有两种
手动添加try{}catch{}使用await-to-js异步错误处理库
到此这篇关于await/async无法捕获与处理错误信息的解决方案的文章就介绍到这了,更多相关await/async无法捕获与处理错误内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！
