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

豌豆花下貓發表於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 關鍵字等內容,可以豐富大家對這個話題的理解,推薦一讀。

相關文章