为什么在 Promise 构造函数中嵌套 `async/await` 是一种反模式？

Promise 构造函数中嵌套 async/await 的反模式

在本例中，使用 async.eachLimit 函数来管理并发操作的数量，就会出现一个困境。最初的诱惑是将代码构造如下：

function myFunction() {
  return new Promise(async (resolve, reject) => {
    eachLimit((await getAsyncArray), 500, (item, callback) => {
      // Operations using native promises
    }, (error) => {
      if (error) return reject(error);
      // Resolve with the next value
    });
  });
}

虽然将“myFunction”函数声明为异步似乎合乎逻辑，但这是不可行的，因为“eachLimit”函数的内部回调仍然存在无法访问。然而，这种方法存在一个重大缺陷：可能存在未处理的错误。

这种方法是反模式的教科书示例，涉及在另一个 Promise 的构造函数中使用 Promise。在这种情况下，未处理错误的风险尤其严重。为了避免这种情况，请考虑以下代码片段：

let p = new Promise(resolve => {
  ""(); // TypeError
  resolve();
});

(async () => {
  await p;
})().catch(e => console.log("Caught: " + e)); // Catches the error.

在这种情况下，虽然第一行抛出异常，但异步箭头函数的“catch”块会妥善处理该错误。正确的错误处理对于保持稳定性并防止代码库中出现意外行为至关重要。

以上是为什么在 Promise 构造函数中嵌套 `async/await` 是一种反模式？的详细内容。更多信息请关注PHP中文网其他相关文章！