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