為什麼在 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中文網其他相關文章！