在 Python 中，失敗不是意外或錯誤，而是程序行為的一部分。多態(tài)不僅體現(xiàn)在成功路徑上的可替換性，更體現(xiàn)在失敗路徑的可預測與可處理。理解失敗的結構化語義，是掌握 Python 面向對象設計、構建健壯系統(tǒng)的關鍵。

7.1 失敗作為正常分支

在許多傳統(tǒng)面向對象設計中，“失敗”常被視為需要避免或隱藏的情況。

但在 Python 的實踐語境中，失敗被視為與成功并列存在、同樣可靠的行為分支。

    value = None    # 正常處理失敗

表達式 mapping[key] 天然包含兩條合法路徑：

? 鍵存在：返回對應值

? 鍵不存在 ：拋出 KeyError

失敗不是隱藏的意外，而是調用方必須正視并處理的正常結果。

失敗路徑的存在，使接口語義更加完整，而不是更加脆弱。

7.2 Python 的異常語義

Python 通過異常機制，為失敗路徑提供了明確且可區(qū)分的語義表達：

    print("屬性不存在")

這些示例展示了 Python 如何通過異常類型，為不同失敗原因賦予精確語義。

異常并不僅僅告訴調用方“失敗了”，而是回答了更關鍵的問題：失敗是如何發(fā)生的、屬于哪一類以及是否可恢復。

因此，在 Python 中，異常是一種結構化的失敗返回機制，而不是簡單的錯誤信號。

異常類型本身，已經(jīng)成為接口對失敗方式的正式承諾。

7.3 多態(tài)中的失敗一致性

在多態(tài)語境下，對象之間的可替換性不僅體現(xiàn)在成功路徑上，也同樣體現(xiàn)在失敗路徑上。

如果不同實現(xiàn)對失敗的表達方式不一致，那么這種多態(tài)只在“順利情況下”成立，一旦進入異常分支便會崩解。

在這個使用語境中，調用方已經(jīng)隱式定義了接口的失敗語義：

? I/O 相關問題應以 OSError 及其子類表達

? 接口不滿足應以 AttributeError 表達

只要實現(xiàn)遵守這一失敗約定，就可以被安全地替換使用。

（1）行為一致的失敗實現(xiàn)

盡管 FileSource 與 NetworkSource 的內(nèi)部實現(xiàn)完全不同，但它們在失敗時：

? 明確拋出異常

? 使用可預期的異常類型

? 將失敗原因清晰暴露給調用方

因此，它們在失敗路徑上依然保持行為一致，能夠共同參與同一個多態(tài)接口。

（2）失敗語義不一致的反例

result = read_all(BadSource())

BadSource 雖然形式上提供了 read() 方法，但在失敗時選擇“沉默返回”，既不說明失敗原因，也不符合既有的失敗語義約定。

對調用方而言，此時無法區(qū)分：返回結果是否真的為空，還是讀取過程中發(fā)生了錯誤。

這種失敗方式破壞了接口的語義一致性，使對象失去可替換性。

在 Python 的多態(tài)體系中，成功路徑需要語義一致，失敗路徑同樣需要語義一致。

失敗方式的不一致，本質上等同于接口不穩(wěn)定。

只有當對象在失敗時也能給出可預測、可理解、可處理的行為，多態(tài)才能在真實系統(tǒng)中長期成立。

7.4 EAFP 與 LBYL 的設計哲學

Python 社區(qū)常討論兩種設計立場：

    value = default  

Python 明顯偏向 EAFP（Easier to Ask Forgiveness than Permission，先嘗試再處理失敗）而不是 LBYL（Look Before You Leap，先檢查再行動），其根本原因在于：

? 失敗在 Python 中是合法行為

? 異常是結構化的失敗表達

如果失敗是混亂的、不可預測的，那么“先嘗試再處理失敗”只會帶來風險。正因為 Python 將失敗視為合法行為，并通過異常進行標準化表達，EAFP 才成為一種可靠的設計哲學。

因此，EAFP 并非“冒險寫法”，而是建立在失敗多態(tài)之上的理性選擇。

7.5 明確失敗條件的接口設計

成熟的 Python 接口，應在設計階段顯式聲明失敗條件。

    print(f"處理成功: {result}")

DataProcessor.process() 的示例體現(xiàn)了一個關鍵思想：成熟的接口，不僅要聲明成功時做什么，更要聲明失敗時會發(fā)生什么。

通過文檔和異常類型，接口明確回答了以下問題：

? 哪些失敗是可能的

? 每種失敗意味著什么

? 調用方應如何區(qū)分與處理

當失敗條件被顯式納入接口語義后，不同實現(xiàn)就可以在相同失敗約定下自由替換，而不會破壞調用方邏輯。

這使得多態(tài)不再只是“成功路徑上的可替換”，而擴展為全行為路徑上的可替換性。

7.6 失敗多態(tài)的實際應用

失敗多態(tài)的價值，并不止于“能被捕獲”，還在于能被統(tǒng)一治理。

fetch_data(CacheSource())

with_retry 并不關心具體的數(shù)據(jù)源類型，也不關心失敗的內(nèi)部原因，它只依賴一個事實：這些對象在失敗時，會以約定的異常形式暴露失敗。

正因為失敗路徑具有一致語義，橫切邏輯（重試、回退、熔斷、降級）才能被抽象出來，獨立于具體實現(xiàn)存在。

這正是失敗多態(tài)在工程層面的現(xiàn)實意義。

小結

在 Python 中，多態(tài)不僅是成功調用的可替換性，更包含失敗路徑的可預期性。異常機制將失敗結構化，使不同對象在成功與失敗上都能遵循一致語義，從而實現(xiàn)真正的行為可替換性。

“點贊有美意，贊賞是鼓勵”