最近看到一些开发者用这种方法来处理async/await错误。/***@param{Promise}promise*@param{Object=}errorExt-您可以传递给错误对象的附加信息*@return{Promise}*/functionto(promise,errorExt){returnpromise.then((data)=>[null,data]).catch((err)=>{if(errorExt){constparsedError=Object.assign({},err,errorExt);return[parsedError,undefined];}return[err,undefined];});}asyncfunctiondoSomething(){const[error1,result1]=awaitto(fetch(''));如果（错误1）{返回；}const[error2,result2]=awaitto(fetch(result1));如果（错误2）{返回；}//...}可以看到，他们把函数包装起来，把原来的Promise转成一定会成功的“Promise”，返回一个数组。如果原Promise成功，则数组第一项为空，表示没有错误，第二项为原Promise的结果。如果原始Promise失败，则数组的第一项为错误，第二项为未定义。就是这样。他们认为它很优雅并且使代码更具可读性。但我不这么认为，也不推荐这样使用。我觉得这样的封装有点过分，在大多数情况下，没有必要这样做。接下来，我将从两个角度阐述我的观点。1、从设计的角度来看，Async/awaitAPI的目的是让开发者像写同步代码一样写异步代码。因此，try...catch可用于捕获异步/等待错误。而这样的一个功能似乎为我们包办了一切，但其他开发者只是看到你的代码，总会有这样的疑惑。为什么to函数返回的Promise使用的await没有用try...catch包裹？只有找到to函数的原始定义，理解它的意图，才能知道“啊，原来to函数返回的Promise永远不会被拒绝”。所以进一步增加了其他开发者的理解成本，让熟悉的async/await不再“耳熟能详”。2、从实际来看，to函数的主要用法是在同一个上下文中有多个awaitpromise，它们对应的错误处理方式不同。然后使用这个包装函数对每个错误进行不同的处理，减少try...catch的使用。但是在实际开发中，在每个函数之后，都需要用一个if语句来判断是否有错误。这和使用try...catch的初衷没有区别，都是为了检查错误。其次，在真实的生产环境中，下一个Promise依赖于上一个Promise的情况并不少见。但重要的一点是，这两个Promise通常是关联函数。所以在外层使用try...catch来统一处理错误是没有问题的。例如：最后，在JavaScript中，大多数Promise场景都是在Input/Output上，比如网络IO和文件IO。这些IO场景可以在lower层封装拦截器，根据错误码统一处理。例如，使用axios拦截器。所以它可能不像预期的那样实用。也就是说，它可能只用于整个项目的一小部分，成本大于收益。以上就是我的全部看法，你怎么看？你同意这种做法吗？
