對比程式語言的四種錯誤處理方法，哪種才是最優方案？

豌豆花下貓發表於2023-05-08

作者：Andrea Bergia

譯者：豌豆花下貓@Python貓

英文：Error handling patterns

轉載請保留作者及譯者資訊！

錯誤處理是程式設計的一個基本要素。除非你寫的是“hello world”，否則就必須處理程式碼中的錯誤。在本文中，我將討論各種程式語言在處理錯誤時使用的最常見的四種方法，並分析它們的優缺點。

關注不同設計方案的語法、程式碼可讀性、演變過程、執行效率，將有助於我們寫出更為優雅和健壯的程式碼。

返回錯誤程式碼

這是最古老的策略之一——如果一個函式可能會出錯，它可以簡單地返回一個錯誤程式碼——通常是負數或者null。例如，C 語言中經常使用：

FILE* fp = fopen("file.txt" , "w");
if (!fp) {
  // 發生了錯誤
}

這種方法非常簡單，既易於實現，也易於理解。它的執行效率也非常高，因為它只需要進行標準的函式呼叫，並返回一個值，不需要有執行時支援或分配記憶體。但是，它也有一些缺點：

  • 使用者很容易忘記處理函式的錯誤。例如，在 C 中，printf 可能會出錯，但我幾乎沒有見過程式檢查它的返回值！
  • 如果程式碼必須處理多個不同的錯誤（開啟檔案，寫入檔案，從另一個檔案讀取等），那麼傳遞錯誤到呼叫堆疊會很麻煩。
  • 除非你的程式語言支援多個返回值，否則如果必須返回一個有效值或一個錯誤，就很麻煩。這導致 C 和 C++ 中的許多函式必須透過指標來傳遞儲存了“成功”返回值的地址空間，再由函式填充，類似於：
my_struct *success_result;
int error_code = my_function(&success_result);
if (!error_code) {
  // can use success_result
}

眾所周知，Go 選擇了這種方法來處理錯誤，而且，由於它允許一個函式返回多個值，因此這種模式變得更加人性化，並且非常常見：

user, err = FindUser(username)
if err != nil {
    return err
}

Go 採用的方式簡單而有效，會將錯誤傳遞到呼叫方。但是，我覺得它會造成很多重複，而且影響到了實際的業務邏輯。不過，我寫的 Go 還不夠多，不知道這種印象以後會不會改觀！?

異常

異常可能是最常用的錯誤處理模式。try/catch/finally 方法相當有效，而且使用簡單。異常在上世紀 90 年代到 2000 年間非常流行，被許多語言所採用（例如 Java、C＃ 和 Python）。

與錯誤處理相比，異常具有以下優點：

  • 它們自然地區分了“快樂路徑”和錯誤處理路徑
  • 它們會自動從呼叫堆疊中冒泡出來
  • 你不會忘記處理錯誤！

然而，它們也有一些缺點：需要一些特定的執行時支援，通常會帶來相當大的效能開銷。

此外，更重要的是，它們具有“深遠”的影響——某些程式碼可能會丟擲異常，但被呼叫堆疊中非常遠的異常處理程式捕獲，這會影響程式碼的可讀性。

此外，僅憑檢視函式的簽名，無法確定它是否會丟擲異常。

C++ 試圖透過throws 關鍵字來解決這個問題，但它很少被使用，因此在 C++ 17 中已被棄用 ，並在 C++ 20 中被刪除。此後，它一直試圖引入noexcept 關鍵字，但我較少寫現代 C++，不知道它的流行程度。

（譯者注：throws 關鍵字很少使用，因為使用過於繁瑣，需要在函式簽名中指定丟擲的異常型別，並且這種方法不能處理執行時發生的異常，有因為“未知異常”而導致程式退出的風險）

Java 曾試圖使用“受檢的異常（checked exceptions）”，即你必須將異常宣告為函式簽名的一部分——但是這種方法被認為是失敗的，因此像 Spring 這種現代框架只使用“執行時異常”，而有些 JVM 語言（如 Kotlin）則完全拋棄了這個概念。這造成的結果是，你根本無法確定一個函式是否會丟擲什麼異常，最終只得到了一片混亂。

（譯者注：Spring 不使用“受檢的異常”，因為這需要在函式簽名及呼叫函式中顯式處理，會使得程式碼過於冗長而且造成不必要的耦合。使用“執行時異常”，程式碼間的依賴性降低了，也便於重構，但也造成了“異常源頭”的混亂）

回撥函式

另一種方法是在 JavaScript 領域非常常見的方法——使用回撥，回撥函式會在一個函式成功或失敗時呼叫。這通常會與非同步程式設計結合使用，其中 I/O 操作在後臺進行，不會阻塞執行流。

例如，Node.JS 的 I/O 函式通常加上一個回撥函式，後者使用兩個引數（error，result），例如：

const fs = require('fs');
fs.readFile('some_file.txt', (err, result) => {
  if (err) {
    console.error(err);
    return;
  }

  console.log(result);
});

但是，這種方法經常會導致所謂的“回撥地獄”問題，因為一個回撥可能需要呼叫其它的非同步 I/O，這可能又需要更多的回撥，最終導致混亂且難以跟蹤的程式碼。

現代的 JavaScript 版本試圖透過引入promise 來提升程式碼的可讀性：

fetch("https://example.com/profile", {
      method: "POST", // or 'PUT'
})
  .then(response => response.json())
  .then(data => data['some_key'])
  .catch(error => console.error("Error:", error));

promise 模式並不是最終方案，JavaScript 最後採用了由 C＃推廣開的 async/await 模式，它使非同步 I/O 看起來非常像帶有經典異常的同步程式碼：

async function fetchData() {
  try {
    const response = await fetch("my-url");
    if (!response.ok) {
      throw new Error("Network response was not OK");
    }
    return response.json()['some_property'];
  } catch (error) {
    console.error("There has been a problem with your fetch operation:", error);
  }
}

使用回撥進行錯誤處理是一種值得了解的重要模式，不僅僅在 JavaScript 中如此，人們在 C 語言中也使用了很多年。但是，它現在已經不太常見了，你很可能會用的是某種形式的async/await。

函式式語言的 Result

我最後想要討論的一種模式起源於函式式語言，比如 Haskell，但是由於 Rust 的流行，它已經變得非常主流了。

它的創意是提供一個Result型別，例如：

enum Result<S, E> {
  Ok(S),
  Err(E)
}

這是一個具有兩種結果的型別，一種表示成功，另一種表示失敗。返回結果的函式要麼返回一個Ok 物件（可能包含有一些資料），要麼返回一個Err 物件（包含一些錯誤詳情）。函式的呼叫者通常會使用模式匹配來處理這兩種情況。

為了在呼叫堆疊中丟擲錯誤，通常會編寫如下的程式碼：

let result = match my_fallible_function() {
  Err(e) => return Err(e),
  Ok(some_data) => some_data,
};

由於這種模式非常常見，Rust 專門引入了一個運運算元（即問號 ?） 來簡化上面的程式碼：

let result = my_fallible_function()?;   // 注意有個"?"號

這種方法的優點是它使錯誤處理既明顯又型別安全，因為編譯器會確保處理每個可能的結果。

在支援這種模式的程式語言中，Result 通常是一個 monad，它允許將可能失敗的函式組合起來，而無需使用 try/catch 塊或巢狀的 if 語句。

（譯者注：函式語言程式設計認為函式的輸入和輸出應該是純粹的，不應該有任何副作用或狀態變化。monad 是一個函式語言程式設計的概念，它透過隔離副作用和狀態來提高程式碼的可讀性和可維護性，並允許組合多個操作來構建更復雜的操作）

根據你使用的程式語言和專案，你可能主要或僅僅使用其中一種錯誤處理的模式。

不過，我最喜歡的還是 Result 模式。當然，不僅是函式式語言採用了它，例如，在我的僱主 lastminute.com 中，我們在 Kotlin 中使用了 Arrow 庫，它包含一個受 Haskell 強烈影響的型別Either。我有計劃寫一篇關於它的文章，最後感謝你閱讀這篇文章，敬請保持關注?。

譯註：還有一篇《Musings about error handling mechanisms in programming languages》文章，同樣分析了不同程式語言在錯誤處理時的方案。它還介紹了 Zig 程式語言的做法、Go 語言的 defer 關鍵字等內容，可以豐富大家對這個話題的理解，推薦一讀。

相關文章