你的錯誤處理方式是錯的！

你錯誤處理錯誤：可預測和標準化回應的案例

簡介：固執己見的立場

JavaScript 中的錯誤處理是一個引起強烈意見的話題，我在這裡分享我的觀點：傳統的 try-catch 方法笨重、不方便且過時。在 Garmingo，我們建立了 Garmingo Status（一種用於正常運行時間和基礎設施監控的 SaaS 解決方案），我們已經放棄了 try-catch 區塊。相反，我們採用了基於 TypeScript 的方法，為非同步操作提供可預測的標準化回應。

本文分享了為什麼我們相信這個範例可以改變開發人員生產力，以及它如何幫助簡化我們的程式碼庫。雖然這是一種固執己見的看法，但我希望它能激勵您重新思考如何處理自己專案中的錯誤。

try-catch 的問題

讓我們面對現實：JavaScript 中的錯誤處理可能會變得混亂。傳統的 try-catch 區塊面臨許多挑戰：

1. 冗長：將每個非同步函數呼叫包裝在 try-catch 中會加入不必要的樣板。它會使您的程式碼變得混亂並降低可讀性。
2. 不一致的錯誤物件：JavaScript 錯誤物件的結構和內容可能會大不相同。如果沒有標準化，處理這些錯誤通常感覺就像在玩猜謎遊戲。
3. 巢狀邏輯地獄：在處理可能失敗的多個操作時，巢狀的 try-catch 區塊會使您的程式碼變得一團亂麻。

這是一個強調這些問題的簡單範例：

try {
  const user = await fetchUser();
  try {
    const account = await fetchAccount(user.id);
    console.log(account);
  } catch (accountError) {
    console.error('Error fetching account:', accountError);
  }
} catch (userError) {
  console.error('Error fetching user:', userError);
}

結果呢？程式碼更難閱讀、調試和維護。

輸入 TypeScript 類型化回應範式

在 Garmingo Status，我們放棄了 try-catch，轉而為所有非同步操作採用標準化回應結構。其工作原理如下：

結構

每個非同步函數都會傳回一個具有預先定義聯合類型的 Promise：

Promise<
  | { success: false; error: string }
  | { success: true; result: T }
>;

此方法可確保：

• 如果操作失敗，結果總是 { success: false, error: string }.
• 如果成功，則為 { success: true, result: T }.
• 如果 success 為 true，則有結果物件且沒有錯誤對象，反之亦然。您甚至不能使用失敗回應的結果。

這是與上面相同的範例，用此模式重寫：

const userResponse = await fetchUser();

if (!userResponse.success) {
  console.error('Error fetching user:', userResponse.error);
  return;
}

const accountResponse = await fetchAccount(userResponse.result.id);

if (!accountResponse.success) {
  console.error('Error fetching account:', accountResponse.error);
  return;
}

console.log(accountResponse.result);

如您所見，它不會為您的應用程式的主要邏輯引入任何巢狀。它只是添加了這些用於錯誤處理的小檢查，但主要流程保持不間斷並且可以繼續，就像一開始就不需要錯誤處理一樣。

可預測和標準化錯誤處理的優點

1. 可預測性

最大的好處是確切地知道會發生什麼事。無論操作成功或失敗，結構都是一致的。這消除了錯誤物件經常帶來的歧義。

2. 易於使用

深度嵌套的 try-catch 區塊的時代已經一去不復返了。使用類型化方法，您可以內聯處理錯誤，而不會破壞程式碼流程。

3. 提高可讀性

結構化方法使您的程式碼更清晰且更易於遵循。每個操作都清楚地定義了成功和失敗場景中會發生什麼。

4. 增強型別安全

TypeScript 的靜態分析可確保您永遠不會忘記處理錯誤。如果您不小心忽略了成功檢查，TypeScript 編譯器將對其進行標記。

平衡的觀點

沒有一種方法是沒有缺點的。類型化回應範例要求您明確檢查每個操作的成功狀態，即使您確信它會成功。與傳統方法相比，這會增加少量開銷，您可以完全避免錯誤處理（儘管風險由您自己承擔）。

然而，這個「缺點」也是它的優點之一：它迫使您批判性地思考潛在的失敗，從而產生更健壯的程式碼。

我們如何在 Garmingo Status 使用它

在 Garmingo，這種方法改變了我們建立非同步實用程式和函式庫的方式。每個 API 呼叫和資料庫查詢都遵循此標準化回應結構，確保我們的程式碼庫的一致性。
事實上，每個在專案中重複使用並且可能失敗的單一非同步函數都使用這種方法。
結果呢？更流暢（更快）的開發體驗和更少的深夜調試會話。

例如，取得函數可能如下所示：

try {
  const user = await fetchUser();
  try {
    const account = await fetchAccount(user.id);
    console.log(account);
  } catch (accountError) {
    console.error('Error fetching account:', accountError);
  }
} catch (userError) {
  console.error('Error fetching user:', userError);
}

這種可預測性改變了我們團隊的遊戲規則，使我們能夠專注於建立功能，而不是理清錯誤處理邏輯。

結論

傳統的 try-catch 區塊有其用武之地，但對於現代 JavaScript 開發——尤其是在 TypeScript 密集的程式碼庫中——它們通常帶來的麻煩超過了它們的價值。透過採用類型化回應範例，您可以獲得可預測性、可讀性和安心感。

在 Garmingo，我們親眼目睹了這種方法如何簡化開發並增強我們交付 Garmingo Status 等精美產品的能力。雖然它可能不適合所有人，但我堅信這是更多開發人員應該考慮的方法。

那麼，您準備好重新考慮錯誤處理了嗎？讓我知道你的想法！

以上是你的錯誤處理方式是錯的！的詳細內容。更多資訊請關注PHP中文網其他相關文章！