1. 異常處理的本質(zhì)先別把它當(dāng)“錯誤”看寫了這么多年 Python我見過太多把異常處理寫成“try 一下然后打印堆?！钡拇a。異常處理看上去是 Python 里最好懂的一部分——try、except、finally 三個關(guān)鍵字誰都能寫幾行——但真正能在生產(chǎn)環(huán)境里扛住事的異常處理遠(yuǎn)不止這幾個關(guān)鍵字那么簡單。裸 except 吞掉錯誤、日志只記一個字符串、線程里的異常主線程毫無感知這些問題幾乎每個稍微有點(diǎn)規(guī)模的 Python 項(xiàng)目里都能翻出來幾個。我寫這篇關(guān)于 Python 中異常處理的文章就是想把我這幾年踩過的坑、排過的障、改過的爛代碼一次性講透。它適合剛?cè)腴T不久、只會寫簡單 try-except 的初學(xué)者也適合寫過一段時間卻總遇到“詭異 Bug”的進(jìn)階用戶。我會先講異常機(jī)制本身是怎么回事再講捕獲時最容易翻車的寫法然后用一個真實(shí)事故的排查過程告訴你“錯誤為什么不該被吞”最后聊清楚自定義異常、異常鏈、并發(fā)場景和性能邊界?？赐曛竽銘?yīng)該能建立起一套自己的異常處理判斷標(biāo)準(zhǔn)。1.1 從 raise 到 except中間發(fā)生了一次棧展開很多人以為異常就是“程序出錯了打印一段紅色文字”其實(shí)異常在 Python 里是一種非常標(biāo)準(zhǔn)的控制流。它的運(yùn)行機(jī)制是這樣某一行代碼執(zhí)行時發(fā)現(xiàn)狀況不對主動raise一個異常對象當(dāng)前這個函數(shù)幀立刻停止執(zhí)行異常順著函數(shù)調(diào)用鏈一層一層往上“冒泡”。這個過程叫棧展開stack unwinding。每一層函數(shù)在退出前都會先執(zhí)行自己的finally塊然后繼續(xù)往上找有沒有能匹配上的except分支?？匆粋€最簡單的例子def build_user(user_id): return int(user_id) def get_user_name(user_id): user build_user(user_id) return user- str(user) try: get_user_name(abc) except ValueError: print(字符串轉(zhuǎn)整數(shù)失敗)當(dāng)int(abc)拋 ValueError 時build_user立刻中斷異常上浮到get_user_name它也沒有處理繼續(xù)上浮到try處被except ValueError接住。整個過程里get_user_name里那句return根本沒有機(jī)會執(zhí)行。理解了這一點(diǎn)你才能明白為什么“把一大段業(yè)務(wù)邏輯塞進(jìn) try 里”是個壞主意——你根本不知道異常是從哪個調(diào)用點(diǎn)冒上來的也就不知道該去哪里修。我還特意強(qiáng)調(diào)過異常是給“意外情況”準(zhǔn)備的不是給“常規(guī)分支”準(zhǔn)備的。如果你寫的代碼里充斥著“try 一下看看會不會出錯出錯就換個方向”那說明你的業(yè)務(wù)邏輯需要的是 if/else 判斷而不是異常。這個度的把握后面第六章會專門展開。1.2 BaseException 與 Exception 之間隔著一堵墻Python 的內(nèi)置異常體系看起來像一棵樹根是BaseException它的直接子類包括Exception以及幾個“非錯誤型”的異常KeyboardInterrupt、SystemExit、GeneratorExit。大多數(shù)人閉著眼睛寫的except Exception只能捕獲到Exception及其子孫捕獲不到這三兄弟。這個設(shè)計是有意的KeyboardInterrupt代表用戶按了 CtrlCSystemExit代表程序主動退出它們都屬于“控制流信號”不應(yīng)該被普通的業(yè)務(wù)異常處理器攔走。這是新手最容易懵的地方。舉個例子while True: try: print(工作中...) except Exception: continue你按 CtrlC程序照樣能退出因?yàn)镵eyboardInterrupt不是Exception的子類except Exception接不住它。但如果你把except Exception換成裸except:那就慘了CtrlC 會被吞掉進(jìn)程怎么都?xì)⒉凰馈＿@個場景我后面會用一個事故案例詳細(xì)講這里先記住一條鐵律注意絕大多數(shù)情況下都不要寫裸except:。它不是用來“捕獲所有錯誤”的正確姿勢而是在“連 CtrlC 都攔”的錯誤姿勢。常用異常的捕獲范圍我整理成了一張表方便你隨手對照寫法捕獲范圍生產(chǎn)環(huán)境建議except:所有異常包括 KeyboardInterrupt / SystemExit不要用except BaseException:同上不要用except Exception:所有常規(guī)業(yè)務(wù)異常慎用要清楚自己在兜什么底except ValueError:單類異常優(yōu)先按具體類型捕獲except (ValueError, TypeError) as e:多類異常統(tǒng)一處理常用適合處理方式相同的場景2. 捕獲異常最容易翻車的三種寫法try-except 看似簡單但我在 Code Review 里見過太多問題代碼。今天把最常見的三種拿出來一個一個講每一種都有真實(shí)項(xiàng)目的影子。2.1 裸 except連 CtrlC 都救不了裸 except 的危害我在 1.2 里已經(jīng)預(yù)告過了。這里給它一個完整的“罪狀清單”吞掉KeyboardInterrupt導(dǎo)致進(jìn)程無法被 CtrlC 中斷吞掉SystemExit程序自己想退出都退不掉吞掉所有真正的業(yè)務(wù)異常排錯信息全部石沉大海給人造成“這段代碼很健壯”的錯覺實(shí)際上只是把故障從明處挪到了暗處。我以前接手過一個內(nèi)部工具里面有個循環(huán)判斷用戶輸入是否合法寫的是try: result validate(input_text) except: result None這段代碼在開發(fā)環(huán)境怎么跑都對一上生產(chǎn)環(huán)境就出現(xiàn)“明明輸入錯了程序卻繼續(xù)往下走最后落了一堆臟數(shù)據(jù)”的情況。查了半天發(fā)現(xiàn)是validate內(nèi)部因?yàn)榫W(wǎng)絡(luò)超時拋了一個TimeoutError也被裸 except 兜住轉(zhuǎn)成了None。問題不是出在輸入校驗(yàn)邏輯本身而是異常被一股腦全吞了。裸 except 的正確替代方案永遠(yuǎn)都是寫出你預(yù)期可能出現(xiàn)的異常類型然后用具體的 except 去接。比如這里應(yīng)該只接ValueErrortry: result validate(input_text) except ValueError: result None這樣網(wǎng)絡(luò)超時這種“意外之?dāng)场辈庞袡C(jī)會往外拋日志才會響。2.2 異常到底該“吃掉”還是“往上拋”很多人的異常處理只有兩條路要么print一下當(dāng)作無事發(fā)生要么raise把異常原樣扔回去。這兩條路本身沒錯錯的是選擇標(biāo)準(zhǔn)。先說“只打印不處理”的問題try: do_something() except Exception as e: print(e)print(e)只打印了異常對象的字符串表示比如“l(fā)ist index out of range”。你只知道出了問題但不知道是哪一個列表、哪一行、在什么上下文里出的。生產(chǎn)環(huán)境里這種日志等于沒有。正確做法是記錄完整堆棧import logging logger logging.getLogger(__name__) try: do_something() except Exception: logger.exception(調(diào)用業(yè)務(wù)模塊失敗)logger.exception會把你當(dāng)前所在位置的完整 traceback 一起寫進(jìn)日志。排查問題的時候堆棧信息遠(yuǎn)比那句“失敗”值錢。再說往上拋。很多人不知道raise和raise e的區(qū)別try: run() except ValueError as e: raise # 保留原始 traceback從最底層開始try: run() except ValueError as e: raise e # 生成新的 traceback原始信息會被截斷在絕大多數(shù)情況下你應(yīng)該用裸raise這樣才能保持異常的完整傳播鏈路。raise e等于把原本從底層函數(shù)一路冒上來的堆棧給“洗”掉了排錯時看到的起點(diǎn)變成了你raise的這一行。尤其當(dāng)調(diào)用鏈有三層以上時這個差別直接決定你排查問題花十分鐘還是兩個小時。到底什么時候該處理什么時候該拋我的經(jīng)驗(yàn)是只有在當(dāng)前這一層你還能“做點(diǎn)什么”的時候才去 catch 它。比如你 catch 到一個數(shù)據(jù)庫連接錯誤決定切換備用庫重試這時候 catch 是有意義的如果你 catch 之后既沒有補(bǔ)償邏輯也沒有額外上下文可以補(bǔ)充那不如直接讓異常往上走讓有能力處理的那一層去接。2.3 多 except 分支的順序是個排序題Python 的多個 except 分支是從上往下依次匹配的第一個匹配上的生效。下面這段代碼是典型反例try: fetch_user() except Exception: print(通用錯誤) except ValueError: print(值錯誤)第二個except ValueError永遠(yuǎn)走不到因?yàn)閂alueError本身就是Exception的子類往上匹配的時候先撞上第一個分支。Python 不會報語法錯誤但這段代碼的意圖已經(jīng)廢了。正確的順序是“具體優(yōu)先通用兜底”try: fetch_user() except ValueError: print(值錯誤) except KeyError: print(鍵錯誤) except Exception: print(兜底錯誤)我自己的習(xí)慣是能寫出具體類型的一定寫具體類型多個具體類型用元組合并處理最后才用Exception兜底而且兜底分支里至少要有l(wèi)ogger.exception不許靜默。寫代碼時腦海里把異常繼承樹過一遍比你事后憑借“感覺”排順序靠譜得多。3. 一次批量任務(wù)“無限重投”事故的完整排查鏈路理論講再多不如一次實(shí)戰(zhàn)來的記憶深刻。這一節(jié)我完整復(fù)盤一個我印象很深的事故一個跑在凌晨的批量消費(fèi)任務(wù)突然從“正常三分鐘跑完”變成“永遠(yuǎn)跑不完”而且 CtrlC 都?xì)⒉坏簟?.1 現(xiàn)象與第一眼印象日志干凈得像什么都沒發(fā)生那個任務(wù)從消息隊(duì)列里拉取待處理的記錄逐條處理。某天早上運(yùn)維反饋任務(wù)已經(jīng)跑了一個半小時還沒結(jié)束隊(duì)列積壓越來越多單核 CPU 一直 100%。我上去第一件事是看日志。日志里每隔幾秒就會出現(xiàn)同一行業(yè)務(wù)打印processing msg id20240811-0015這行重復(fù)了幾百遍。奇怪的是沒有任何 traceback沒有任何異常日志。一條消息反復(fù)出現(xiàn)在日志里說明這個msg id20240811-0015一直在被拉取、被處理、然后又回來。當(dāng)時的直覺告訴我這條消息的處理一定在某個地方不斷失敗而失敗原因被某種機(jī)制吞掉了。3.2 用棧采樣工具讓卡住的地方現(xiàn)形日志看不出來異常人又沒法跟在代碼里跑這時候我選擇讓運(yùn)行中的進(jìn)程“自己開口說話”。Python 生態(tài)里有個棧采樣思路給運(yùn)行中的進(jìn)程發(fā)信號讓它把當(dāng)前每個線程正在執(zhí)行的代碼棧打印出來。簡單說就是讓程序告訴我們它此刻“正停在哪一行”。我采到的堆棧長這樣省略了無關(guān)幀Thread 0x7f3c...: File consume.py, line 24, in module consume_forever() File consume.py, line 18, in consume_forever handler.handle(msg) File consume.py, line 11, in consume_forever continue雖然采樣打到的具體行在不斷跳動但有一個信息非常明確主線程一直在consume_forever的while True循環(huán)里轉(zhuǎn)而且每次經(jīng)過handler.handle(msg)之后都進(jìn)入了continue。一個continue本身沒什么但結(jié)合“同一個 msg id 反復(fù)出現(xiàn)”基本可以確定循環(huán)體在處理這條固定消息時不斷拋錯、又不斷被吞掉。3.3 根因定位裸 except 把隊(duì)列重投與中斷信號一起吞了打開源碼問題全貌立刻浮出水面while True: try: msg broker.receive() handler.handle(msg) broker.ack(msg) except: continue這段代碼有三個連環(huán)錯誤。第一handler.handle(msg)對那條壞消息必然拋異常裸except:把所有異常都吞了處理失敗的真實(shí)原因完全沒有記錄。第二broker.ack(msg)和handler.handle(msg)擠在同一個 try 塊里。處理失敗時ack根本沒有機(jī)會執(zhí)行。隊(duì)列服務(wù)是按 at-least-once 語義投遞消息的不 ack 就當(dāng)作沒消費(fèi)成功過一會兒重新投遞。于是這條消息不停地被重新投遞任務(wù)就陷入無限重試。第三裸except:連KeyboardInterrupt都吞掉了。我們按 CtrlC 想終止進(jìn)程進(jìn)程毫無反應(yīng)因?yàn)橹袛嘈盘柋贿@個 except 當(dāng)成普通異常接住然后continue又回到循環(huán)頂部繼續(xù)跑。我把癥狀和原因?qū)?yīng)起來一目了然現(xiàn)象根因日志只有重復(fù)的業(yè)務(wù)打印沒有 traceback異常被except: continue吞掉同一 msg_id 反復(fù)出現(xiàn)ack 未執(zhí)行隊(duì)列按語義重投CtrlC 無效裸 except 捕獲了 KeyboardInterruptCPU 打滿循環(huán)內(nèi)快速失敗、快速重試無限空轉(zhuǎn)3.4 修復(fù)方案讓異常在該響的地方響起來改法其實(shí)不復(fù)雜核心是拆分職責(zé)接收消息時的超時屬于“正常等待”處理失敗屬于“業(yè)務(wù)異常”確認(rèn)消費(fèi)應(yīng)該放在處理成功之后。while True: try: msg broker.receive() except TimeoutError: # 短時間內(nèi)沒有新消息正常 continue try: handler.handle(msg) except Exception: logger.exception(處理消息失敗, msg_id%s, getattr(msg, id, None)) broker.move_to_dlq(msg) # 送死信隊(duì)列避免無限重投 continue broker.ack(msg)改動點(diǎn)逐個說用except TimeoutError替代裸 except——TimeoutError才是這個場景里預(yù)期會出現(xiàn)的異常continue是合理的正常行為handle失敗時調(diào)用logger.exception把 traceback 和 msg_id 一起記錄讓它成為一個“響的異常”失敗消息進(jìn)死信隊(duì)列后續(xù)人工排查而不是讓隊(duì)列服務(wù)一遍遍重投ack放在handle成功之后、自己的 try 塊之外保證“只有真正處理成功才確認(rèn)消費(fèi)”。復(fù)盤時我們給團(tuán)隊(duì)立了一條規(guī)矩異常默認(rèn)應(yīng)該大聲。吞掉異常的那一刻必須寫清楚為什么可以吞以及配套的告警在哪。我現(xiàn)在看別人代碼第一個搜索的就是except: pass和except Exception: pass出現(xiàn)一處審一處基本沒有誤傷。4. finally、return 與上下文管理器資源清理該放哪邊異常處理不只包括“捕獲什么”還包括“退出時干什么”。Python 里負(fù)責(zé)“退出清理”的主要是finally和with語句。這一節(jié)說的都是我在代碼里真實(shí)見到過的坑。4.1 finally 里的 return 會悄悄覆蓋 try 里的 returnfinally的語義是無論 try 塊是正常結(jié)束、異常結(jié)束、還是執(zhí)行了 return 結(jié)束finally里的代碼都一定會跑。很多人以為這是“收尾專用”確實(shí)沒錯但收尾代碼里如果寫了return就會引發(fā)一個反直覺的行為。def compute(): try: return 42 finally: return 0 print(compute()) # 輸出 0try里的return 42已經(jīng)把返回值放進(jìn)寄存器了但在真正交出控制權(quán)之前Python 會先去執(zhí)行finallyfinally里的return 0直接把這個返回值替換掉了。最終函數(shù)返回的是 0不是 42。我最初見到這段代碼時以為是 IDE 顯示問題后來才意識到這是 CPython 的明確語義。同樣危險的是finally里的continue和break它們也會覆蓋 try 塊里已有的跳轉(zhuǎn)意圖。所以我的建議很干脆finally里只做清理動作比如關(guān)文件、關(guān)連接、恢復(fù)配置絕對不要 return、break、continue。還有個更隱蔽的坑finally里的清理代碼本身如果又拋異常會覆蓋原始異常。try: do_risky() finally: cleanup() # 假如這里拋了 OSError原本的異常會被清理代碼的異常頂?shù)裟悴槿罩緯r只能看到OSError真正的業(yè)務(wù)異常反而被覆蓋了。這也是為什么現(xiàn)代 Python 推薦用with語句而不是手動 try/finally 來做資源清理。4.2 with 語句為什么比手動 try/finally 更省心with語句本質(zhì)上調(diào)用對象的__enter__和__exit__兩個魔術(shù)方法。文件對象之所以能配合with使用是因?yàn)樗腳_exit__里封裝了“關(guān)閉文件”的邏輯with open(data.txt, r, encodingutf-8) as f: content f.read()這段代碼等價于f open(data.txt, r, encodingutf-8) try: content f.read() finally: f.close()差異在于with把“退出時該做什么”固化在對象自身里調(diào)用方不需要每次手寫清理邏輯。文件對象、鎖對象、數(shù)據(jù)庫連接、socket 連接等只要實(shí)現(xiàn)了上下文管理協(xié)議你就應(yīng)該優(yōu)先用with。它能保證即使函數(shù)提前 return、即使函數(shù)中途拋異常資源也會被釋放。__exit__有個特性值得說一句它會收到exc_type、exc_value、exc_tb三個參數(shù)。如果__exit__返回了True異常會被抑制不再往外傳播。很多初學(xué)者自己實(shí)現(xiàn)上下文管理器時容易在這里踩坑__exit__返回一個非 None 的值異常被莫名吞掉。除非你是故意要抑制否則__exit__應(yīng)該返回False或 None。4.3 contextlib 里的三個實(shí)用工具Python 標(biāo)準(zhǔn)庫contextlib里有一批好用的工具能讓你少寫很多樣板代碼。第一個是contextlib.suppress適合“明確知道某個異?？梢院雎浴钡膱鼍癴rom contextlib import suppress import os with suppress(FileNotFoundError): os.remove(temp.log)等價于try: os.remove(temp.log) except FileNotFoundError: pass它比 try/except/pass 的優(yōu)勢是意圖清晰正在表達(dá)“這個文件刪除失敗是因?yàn)樗緛砭筒淮嬖谶@不重要”。注意 suppress 里的異常類型要盡量具體別在這里放Exception否則又變成裸吞了。第二個是contextlib.closing適合那些只有close()方法、沒有實(shí)現(xiàn)__exit__的資源對象from contextlib import closing with closing(get_legacy_client()) as client: client.query(...)第三個是我用得最多的contextlib.contextmanager它允許你用生成器函數(shù)寫自定義上下文管理器。比如我想臨時改一組配置、用完自動恢復(fù)就可以這樣寫from contextlib import contextmanager contextmanager def patch_config(config, **kwargs): backup {key: config.get(key) for key in kwargs} config.update(kwargs) try: yield finally: for key, value in backup.items(): if value is None: config.pop(key, None) else: config[key] value with patch_config(config, timeout10, retries3): run_experiment()這里的關(guān)鍵點(diǎn)是yield必須放在try里面。因?yàn)閣ith塊里的代碼一旦拋異常異常會從yield處重新拋進(jìn)生成器函數(shù)你才有機(jī)會在finally里做恢復(fù)。如果把try放在yield外面異常進(jìn)來時清理邏輯根本不會執(zhí)行。5. 自定義異常、異常鏈與日志讓報錯信息真正可診斷生產(chǎn)環(huán)境里最有價值的異常處理產(chǎn)出物是一句“能把問題定位到具體上下文”的報錯信息。這方面有三個工具極其重要異常鏈、自定義異常體系以及正確的日志姿勢。5.1 異常鏈raise from 與causePython 在異常傳播時天然支持“鏈?zhǔn)缴舷挛摹?。?dāng)你在except塊里再raise一個新異常時新異常會自動帶上原始異常作為上下文打印出來就是兩段 traceback。但這樣產(chǎn)生的上下文有時不夠精確應(yīng)該用raise ... from ...來顯式聲明因果關(guān)系?？匆粋€我經(jīng)常舉的配置加載例子import json class ConfigError(Exception): pass try: with open(config.json, encodingutf-8) as fp: cfg json.load(fp) except FileNotFoundError as e: raise ConfigError(配置文件不存在: config.json) from e except json.JSONDecodeError as e: raise ConfigError(配置文件不是合法JSON) from efrom e會設(shè)置新異常的__cause__屬性traceback 里會出現(xiàn)一行“The above exception was the direct cause of the following exception”把底層原因和上層表現(xiàn)串起來。排查線上問題時這種鏈?zhǔn)叫畔⒛茏屇銖摹芭渲梦募皇呛戏↗SON”一路追到具體是哪一行解析失敗。有時候你想徹底切斷上下文比如底層只是一個單純的字符串轉(zhuǎn)整數(shù)失敗上層錯誤信息已經(jīng)完全說明了情況這時可以用from Nonetry: return int(user_input) except ValueError: raise InvalidInput(必須輸入整數(shù)) from Nonefrom None會設(shè)置__suppress_context__Traceback 只顯示新的異常不再展示背景里那個白噪聲一樣的轉(zhuǎn)換錯誤。用什么時機(jī)我的標(biāo)準(zhǔn)是底層異常信息對解決當(dāng)前問題沒有增量價值時可以用from None切斷否則盡量保留。5.2 自定義異常體系怎么搭給一個稍微上點(diǎn)規(guī)模的項(xiàng)目寫異常處理量身定制的異常類比直接用內(nèi)置異常合適得多。內(nèi)置異常表達(dá)的是“語法級/運(yùn)行級”的錯誤業(yè)務(wù)異常應(yīng)該表達(dá)“這個業(yè)務(wù)領(lǐng)域里發(fā)生了什么不滿足預(yù)期的事”。我常用的搭建方式是定義一個項(xiàng)目根異常然后按模塊或業(yè)務(wù)領(lǐng)域分派子類。class ToolError(Exception): 整個工具所有異常的基類 class ConfigError(ToolError): pass class NetworkError(ToolError): pass class DataValidError(ToolError): pass這樣設(shè)計有立竿見影的好處調(diào)用方如果只想整體兜住業(yè)務(wù)異常可以except ToolError如果只想處理配置錯誤可以except ConfigError兩全其美。自定義異常還可以帶上結(jié)構(gòu)化屬性。比如配置異常不僅要說明“路徑不對”還要把路徑字符串本身存起來方便后續(xù)自動化處理class ConfigError(ToolError): def __init__(self, message, path): self.path path super().__init__(f{message} (path{path}))帶屬性的異常在排障時尤其好用日志關(guān)鍵字可以直接提取。但要提醒一點(diǎn)不要在異常體系里繼承多個內(nèi)置異常搞“多重身份”那會讓匹配規(guī)則變成一團(tuán)漿糊。一個項(xiàng)目一個根根下面分層就足夠解決絕大多數(shù)問題。5.3 日志里只記一個 str(e) 等于白記異常處理最常見的敗筆之一就是把異常對象轉(zhuǎn)成字符串塞進(jìn)普通日志。舉個反例try: result pay_service.pay(order_id, amount) except PayTimeout: logger.error(f支付超時: {PayTimeout})這段日志記錄了“支付超時”四個字僅此而已。沒有訂單號、沒有金額、沒有發(fā)起支付的時間、沒有當(dāng)時重試到第幾次、沒有堆棧。事后你想復(fù)盤連從哪一行發(fā)起支付都查不到。正確寫法是import logging logger logging.getLogger(__name__) try: result pay_service.pay(order_id, amount) except PayTimeout: logger.exception(支付超時, order_id%s, amount%s, attempt%s, order_id, amount, attempt) raise OrderHandleError(支付結(jié)果未知需要人工確認(rèn)) from None兩個細(xì)節(jié)值得展開。一是logger.exception只能在except塊里調(diào)用因?yàn)樗腔趕ys.exc_info()獲取當(dāng)前異常的。如果你在 except 外面調(diào)用logger.exception日志里只會出現(xiàn)一句NoneType: None沒有任何價值。二是日志參數(shù)用占位符而不是 f-string。logger.exception(... order_id%s, order_id)會在日志系統(tǒng)內(nèi)部按需格式化而 f-string 會在傳入前就拼接好字符串。兩者在結(jié)果上差不多但占位符方式不會額外創(chuàng)建字符串對象在高頻日志路徑上更省內(nèi)存也能避免某些奇怪的類型轉(zhuǎn)換異常把日志系統(tǒng)也帶崩。如果你用的 Python 版本是 3.11 及以上還有個非常好的原生氣笽BaseException.add_note。它可以在異常向上傳播的過程中給異常不斷追加上下文try: response http_get(url) except TimeoutError as e: e.add_note(frequest_url{url}, attempt{retry}, timeout_ms{timeout_ms}) raise每一層都可以往里加自己觀察到的信息最后打出來的 traceback 會把這些 note 一并展示。這比在異常字符串里手工拼上下文優(yōu)雅得多排查跨層問題時尤其好使。6. 線程、asyncio 與性能邊界異常處理的高階必修課把單線程流程里的異常處理寫對已經(jīng)能解決 80% 的問題。剩下 20% 集中在并發(fā)場景和性能權(quán)衡上這兩個方向是我見過最多“代碼看著沒問題跑起來就是不對”的重災(zāi)區(qū)。6.1 線程里拋異常主線程根本接不到Python 的線程各自跑各自的函數(shù)棧所謂的“主線程 try/except 包住子線程函數(shù)”是完全無效的?？催@段import threading def worker(): raise RuntimeError(booom) t threading.Thread(targetworker) t.start() t.join() print(任務(wù)執(zhí)行完成)worker里的RuntimeError只會在子線程內(nèi)部打印出 traceback然后線程退出。t.join()不會把它拋到主線程主線程照樣接著打印“任務(wù)執(zhí)行完成”。如果你的排障方式是在join()外面包一層 try/except那我可以直接告訴你白包了異常根本不會經(jīng)過那個 try。解決這個問題最簡單的路徑是讓concurrent.futures幫你管理線程并利用Future.result()把異常帶回調(diào)用方from concurrent.futures import ThreadPoolExecutor def handle(item): return 100 // item with ThreadPoolExecutor(max_workers4) as pool: futures [pool.submit(handle, item) for item in items] for fut in futures: value fut.result() # 這里的異常會拋回主線程fut.result()在任務(wù)執(zhí)行異常時會重新拋出子線程里發(fā)生的異常這時候你的 try/except 才有意義。如果你堅持用裸threading.Thread那就得自己用隊(duì)列把異常傳回來代碼會繁瑣很多除非有特殊理由否則推薦直接上線程池。6.2 asyncio 任務(wù)里的異常gather 與取消阻塞asyncio 的異常傳播路徑同樣不直觀。asyncio.create_task創(chuàng)建的任務(wù)會被事件循環(huán)調(diào)度如果你創(chuàng)建任務(wù)后既不await也不cancel任務(wù)里的異常就會被靜默吞掉等任務(wù)對象被垃圾回收時控制臺才會冒出一句“Task exception was never retrieved”。看這個例子import asyncio async def fetch(i): if i 2: raise RuntimeError(ffetch {i} failed) return i async def main(): tasks [asyncio.create_task(fetch(i)) for i in range(3)] # 如果直接走task 2 的異常被靜默丟棄 # 正確姿勢 results await asyncio.gather(*tasks, return_exceptionsTrue) for result in results: if isinstance(result, Exception): print(任務(wù)異常:, type(result).__name__, result) asyncio.run(main())asyncio.gather提供了兩種處理模式默認(rèn)模式下只要有一個任務(wù)拋異常整個 gather 立刻傳播異常設(shè)置return_exceptionsTrue之后異常對象會作為返回值塞進(jìn) results 列表里由你逐個判斷。批量并發(fā)任務(wù)時用后者非常順手因?yàn)槟阃ǔ２幌胍驗(yàn)橐粭l失敗就放棄其它已成功的任務(wù)。如果你在create_task和await之間還做了取消操作要格外小心CancelledError。它繼承自BaseException不是Exception所以except Exception也接不到通常也不應(yīng)該去接。正確的做法是讓取消信號正常穿透如果需要做清理用try/finally在 finally 里收尾。6.3 別用異常當(dāng)業(yè)務(wù)分支也別因?yàn)椤靶阅堋辈桓矣卯惓Ｐ阅苓@個事被討論過很多次很多人對 Python 異常的印象是“異常很慢別用”。這句話只說對了一半。try塊本身在正常情況下幾乎零開銷因?yàn)?Python 解釋器在執(zhí)行字節(jié)碼時并不會預(yù)支檢查。真正貴的是raise的那一刻解釋器要構(gòu)建異常對象、填寫 traceback 棧幀信息、再執(zhí)行棧展開。所以“寫 try/except 會拖慢程序”這個說法不準(zhǔn)確準(zhǔn)確說法是“頻繁拋出異常會拖慢程序”。這個特性給了我們一個清晰的分寸感如果一個錯誤情況幾乎不會發(fā)生它是真正的“意外”放心用異常別為了省這點(diǎn)開銷去寫一堆防御性 if如果一個錯誤情況經(jīng)常發(fā)生比如用戶字段缺失、數(shù)據(jù)缺失是常規(guī)業(yè)務(wù)狀態(tài)那就用 if/else 或默認(rèn)值不要用異常來傳業(yè)務(wù)信號。Python 社區(qū)有個經(jīng)典討論叫 LBYLLook Before You Leap和 EAFPEasier to Ask for Forgiveness than Permission后者更貼合 Python 風(fēng)格?？催@個例子# LBYL 風(fēng)格 if age in data: age int(data[age]) else: age 0 # EAFP 風(fēng)格 try: age int(data[age]) except KeyError: age 0兩種寫法都能用但我更推薦把“try”縮小到真正可能出錯的表達(dá)式上。比如上面 EAFP 的寫法可以再細(xì)分int(data[age])這一步可能拋KeyError、TypeError、ValueError三種異常如果只用except KeyError接其它兩種會正常冒出來這反而幫了你——數(shù)據(jù)存在但格式不對是另一個等級的問題應(yīng)該讓它發(fā)出聲音。再補(bǔ)一個高頻壞習(xí)慣把互不相關(guān)的多行操作塞進(jìn)同一個 try 里。比如try: do_a() do_b() except OSError: cleanup()如果do_b拋了OSError你很難判斷問題出在 a 還是 b而且你的cleanup()可能只對 a 的狀態(tài)有效。把 try 塊盡量收窄到單條可能失敗的操作catch 到異常后你才能準(zhǔn)確知道“是誰失敗了、需要清理什么”。最后說個我自己的經(jīng)驗(yàn)異常處理和日志一樣屬于“平時多花一分鐘排查省兩小時”的活兒。我寫代碼時的自檢順序很簡單——先問這段代碼會不會發(fā)生預(yù)期外的失敗再問失敗后我希望它繼續(xù)沉默還是向上報最后問報出去的信息是否足以讓一個不看代碼的人定位問題。三個問題過完異常處理基本不會出錯。