C++ 異常處理的效能代價：編譯期、執行期與最佳化策略

無處不在的隱性成本

即使程式完全未使用 try/throw/catch，啟用異常支援的編譯器仍需付出代價：

• 程式碼體積膨脹： 需產生追蹤物件建構狀態、try 區塊邊界、catch 類型匹配表的資料結構與輔助代碼。
• 執行速度下降： 每個物件建構/解構、函數進出皆需更新異常處理元數據。

典型數據：支援異常的建置比不支援的大 5%-10%、慢 5%-10% (視編譯器實作而定)。

編譯器允許關閉異常支援

理論上 C++ 標準要求編譯器支援異常，但主流編譯器 (MSVC, GCC, Clang) 皆提供關閉異常的編譯選項 (如 /EHsc-, -fno-exceptions)。適用場景：

• 專案確定不使用異常，且連結的第三方庫也不使用。
• 嵌入式/高效能場景極度敏感時。

風險： 若程式碼或庫實際拋出異常，行為未定義 (通常直接終止)。隨著標準庫與現代框架廣泛使用異常，此選項適用範圍逐年縮小。

try 區塊與異常規格的額外開銷

• try 區塊： 進入/離開需設置/清理異常處理框架。估計 代碼膨脹 5%-10%，同比例減速 (假設無異常拋出)。
• 異常規格 throw(Type)： 編譯器產生的檢查代碼與 try 幾乎同等開銷。不是免費的文檔！

原則：僅在真正需要捕獲處的地方使用 try，避免濫用異常規格。

拋出異常的高昂代價

拋出異常比正常函數返回慢 3 個數量級 (約 1000 倍)。 涉及：堆疊展開、尋找匹配 catch、呼叫沿途解構函數、複製異常物件等複雜流程。

• 但異常本應是 「罕見/異常情況」 (80-20 法則)，整體效能影響通常可接受。
• 嚴禁用於控制流程： 如用異常結束迴圈、遍歷資料結構 — 將導致災難性效能。

數據來源誠實聲明

具體數字基於傳聞與早期基準測試，而非嚴謹大樣本統計。編廠鮮少公開詳細異常效能數據，實作差異極大。重點在定性認知，非定量依賴。

最小化異常開銷的實務策略

1. 能關閉異常支援編譯就關閉 (確認全專案與依賴庫均不使用時)。
2. 極度克制使用 try 區塊與異常規格，僅在真正需處理處佈置。
3. 只在真正異常情況拋出，拒絕用於常規控制流。
4. 遇到效能瓶頸時，整體剖析 確認異常機制確為熱點，再考慮更換編譯器或重構熱點路徑 (如改用錯誤碼)。

異常處理是強大的正確性工具，但非零成本。善用它的關鍵在於：只為錯誤付費，不為正常流程付費。