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 中国語 Web サイトの他の関連記事を参照してください。