async/await 是 ES7 中引入的語法糖，它徹底改變了 JavaScript 中異步編程的方式。它讓我們能夠以一種看似同步的方式編寫異步代碼，極大地提高了代碼的可讀性和可維護性。

然而，凡事皆有兩面。當我們享受 async/await 帶來的便利時，一個“老朋友”卻如影隨形，那就是 try...catch。

問題的根源：無處不在的 try...catch

為了捕獲 await 后面 Promise 的 reject 狀態，我們必須將代碼包裹在 try...catch 塊中。讓我們來看一個典型的例子，比如從服務器獲取用戶信息：

import { fetchUserById } from './api';

async function displayUser(userId) {
  try {
    const user = await fetchUserById(userId);
    console.log('用戶信息:', user.name);
    // ... 更多基于 user 的操作
  } catch (error) {
    console.error('獲取用戶失敗:', error);
    // ... 相應的錯誤處理邏輯，比如顯示一個提示
  }
}

這段代碼本身沒有問題，它能正常工作。但問題在于，如果你的業務邏輯稍微復雜一點，比如需要連續請求多個接口，代碼就會變成這樣：

async function loadPageData(userId) {
 try {
    const user = await fetchUserById(userId);
    console.log('用戶信息:', user.name);

    try {
      const posts = await fetchPostsByUserId(user.id);
      console.log('用戶文章:', posts);

      try {
        const comments = await fetchCommentsForPosts(posts[0].id);
        console.log('文章評論:', comments);
      } catch (commentError) {
        console.error('獲取評論失敗:', commentError);
      }
    } catch (postError) {
      console.error('獲取文章失敗:', postError);
    }
  } catch (userError) {
    console.error('獲取用戶失敗:', userError);
  }
}

看到這些層層嵌套的 try...catch，你是否感到了一絲窒息？這種寫法存在幾個明顯的問題：

1. 代碼冗余：每個異步操作都需要重復的 try...catch 結構，增加了大量樣板代碼。
2. 可讀性差：核心的“快樂路徑”（Happy Path）代碼被包裹在 try 塊中，增加了縮進層次，干擾了正常的閱讀流。
3. 關注點混合：成功邏輯和失敗邏輯緊密地耦合在同一個代碼塊里，使得函數職責不夠單一。

那么，有沒有一種方法可以擺脫這種困境呢？答案是肯定的。

優雅的解決方案：Go 語言風格的錯誤處理

我們可以借鑒 Go 語言的錯誤處理模式。在 Go 中，函數通常會返回兩個值：result 和 error。調用者通過檢查 error 是否為 nil 來判斷操作是否成功。

我們可以將這種思想引入到 JavaScript 的 async/await 中。創建一個輔助函數（我們稱之為 to），它接收一個 Promise作為參數，并且永遠不會被 reject。相反，它總是 resolve 一個數組，格式為 [error, data]。

• 如果 Promise 成功 resolve，它返回 [null, data]。
• 如果 Promise 失敗 reject，它返回 [error, null]。

讓我們來實現這個 to 輔助函數。

如果你不使用 TypeScript，純 JavaScript 版本如下：

這個 to 函數非常小巧，但威力巨大。它將 try...catch 的邏輯封裝在了內部，向我們暴露了一個統一、扁平的接口。

實踐應用：重構我們的代碼

現在，讓我們用新的 to 函數來重構之前的 displayUser 函數：

看看發生了什么變化：

1. 沒有 try...catch 了！ 整個函數體變得非常扁平。
2. 錯誤優先處理：我們首先通過一個 if 語句檢查并處理錯誤（這被稱為“衛語句”或 Guard Clause），然后提前返回。
3. 可讀性極高：處理完錯誤后，剩下的代碼都是成功路徑下的核心邏輯，一目了然，不再有任何嵌套。

現在，我們再來挑戰那個恐怖的嵌套地獄 loadPageData：

簡直是天壤之別！代碼變成了線性的、可預測的流程，每個步驟的錯誤處理都清晰獨立。

新模式的優勢總結

1. 代碼更扁平、更清晰：消除了 try...catch 的嵌套，讓核心邏輯處于頂層作用域。
2. 減少樣板代碼：將錯誤處理邏輯封裝在可復用的 to 函數中。
3. 強制性的錯誤處理：解構賦值 const [error, data] 迫使開發者正視 error 的存在，不容易遺漏錯誤處理。
4. 關注點分離：通過衛語句將錯誤處理邏輯與成功邏輯分離開，代碼更易于維護。

配合 Promise.all 使用

這個模式在處理多個并發請求時同樣表現出色。

async function loadDashboard(userId) {
 const [
    [userError, userData],
    [settingsError, settingsData]
  ] = await Promise.all([
    to(fetchUser(userId)),
    to(fetchUserSettings(userId))
  ]);

 if (userError) {
    console.error('加載用戶數據失敗');
    // 處理用戶錯誤
  }

 if (settingsError) {
    console.error('加載用戶設置失敗');
    // 處理設置錯誤
  }

 // 即使其中一個失敗，另一個成功的數據依然可用
 if (userData) {
    // ...
  }
 if (settingsData) {
    // ...
  }
}

使用 Promise.all 配合 to 函數，你可以優雅地處理多個 Promise 并發執行時部分成功、部分失敗的場景，而傳統的 try...catch 會在任何一個 Promise 失敗時直接進入 catch 塊，導致所有結果丟失。

try...catch 是 JavaScript 錯誤處理的基石，我們并非要完全消滅它。實際上，我們的 to 函數內部就使用了它。關鍵在于，我們應該將它抽象和封裝起來，而不是在業務代碼中一次又一次地手動編寫。

閱讀原文：https://mp.weixin.qq.com/s/iBK0AUavQeRzOvKBbm7uCw