Python 處理錯誤的原則

處理「異常情況」是編程中爭論最多的問題之一。這可能是因為風險很大：處理不當的錯誤值甚至可以使龐大的系統癱瘓。由於「異常情況」從本質上來說，是測試不足的，但發生的頻率卻令人不快，因此，是否正確處理它們往往可以將一個噩夢般的系統與一個「可以工作」的系統區分開來。

從 Java 的 checked 異常，到 Erlang 的故障隔離，再到 Haskell 的 Maybe，不同的語言對錯誤處理的態度截然不同。

這兩條 Python 之禪是 Python 對這個話題的冥思。

錯誤絕不應該悄悄傳遞... Errors should never pass silently…

當 Python 之禪在 Tim Peters 眼裡閃爍而出之前，在維基百科被俗稱為「維基」之前，第一個維基網站 C2 就已經存在了，它是一個編程指南的寶庫。這些原則大多來自於 Smalltalk 編程社區。Smalltalk 的思想影響了許多面向對象的語言，包括 Python。

C2 維基定義了 武士原則 Samurai Principle ：「勝利歸來，要麼不歸。」用 Python 人的術語來說，它鼓勵摒棄 哨兵值 sentinel value ，比如用返回 None 或 -1 來表示無法完成任務，而是採用引發異常的方式。一個 None 是無聲的：它看起來像一個值，可以放在一個變數中，然後到處傳遞。有時，它甚至是一個有效的返回值。

這裡的原則是，如果一個函數不能完成它的契約，它應該「高調失敗」：引發一個異常。所引發的異常永遠不會看起來像是一個可能的值。它將跳過 returned_value = call_to_function(parameter) 行，並上升到調用棧中，可能使程序崩潰。

崩潰的調試是很直接的：有一個堆棧跟蹤來指示問題以及調用堆棧。崩潰可能意味著程序的必要條件沒有滿足，需要人為干預。它可能意味著程序的邏輯有問題。無論是哪種情況，高調失敗都比一個隱藏的、「缺失」的值要好。用 None 來感染程序的有效數據，直到它被用在某個地方，就如你可能已經知道的，錯誤信息會說 「None 沒有方法進行拆分」。

除非顯式消除 Unless explicitly silenced

有時需要顯式地捕獲異常。我們可能會預見到文件中的某些行格式錯誤，並希望以特殊的方式來處理它們，也許可以把它們放在一個「需要人來看看的行」的文件中，而不是讓整個程序崩潰。

Python 允許我們用 except 來捕獲異常。這意味著錯誤可以被顯式消除。這種明確性意味著 except 行在代碼審查中是可見的。質疑為什麼應該在這裡顯式消除異常並從異常中恢復，是有意義的。自問一下我們是否捕獲了太多或太少的異常也是有意義的。

因為這些全都是明確的，所以有人可以閱讀代碼並了解哪些異常是可以恢復的。

via: https://opensource.com/article/19/12/zen-python-errors

作者：Moshe Zadka 選題：lujun9972 譯者：wxy 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive