[[378993]]

這是 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 行在代碼審查中是可見的。質疑為什么應該在這里顯式消除異常并從異常中恢復，是有意義的。自問一下我們是否捕獲了太多或太少的異常也是有意義的。

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