您现在的位置：程式碼之家 >> 編程語言 > >> .NET 網頁程式設計 >> 關於.NET

CLR 未處理例外處理機制深度解析

編輯：關於.NET

前言：為什麼要理解未處理例外處理？

當應用程式因未處理例外而崩潰時，未處理例外處理 是最後一道防線。它不僅決定應用程式如何結束，更關鍵地提供了診斷根因的最後機會——透過事件日誌、Watson 儲存桶與堆疊追蹤。本文將從 CLR 內部機制出發，系統性剖析 .NET Framework 2.0+ 中托管例外的未處理處理流程。

托管程式碼拋出例外時，CLR 從擲出點最近的托管框架開始，沿著呼叫堆疊向上搜尋 catch 區塊或符合條件的托管篩選器。找到處理器後，CLR 執行 第二階段（Unwind）：從擲出點到處理器之間的所有 finally/fault 區塊。最後在處理器中繼續執行。

能執行托管程式碼的執行緒分兩類，其未處理例外觸發機制截然不同：

執行緒類型	建立者	CLR 是否控制基礎框架	範例
CLR 建立的執行緒	CLR	是	`System.Threading.Thread`、Finalizer 執行緒、ThreadPool 執行緒
非 CLR 建立的執行緒	原生碼（COM、Host API、反向 P/Invoke）	否	進入點執行緒、COM Interop 執行緒、CLR Host API 執行緒

最佳實務：避免使用 catch(Exception) 這類廣義捕捉，它們在語義上等同於 1.x 的吞噬行為，會掩蓋真實錯誤。應捕捉具體例外類型，並盡可能貼近擲出點處理。

例外若在托管碼未被處理，會以原生 SEH 例外形式繼續向上傳播，由 OS 尋找處理器。兩種結果：

Windows 允許進程註冊全域 UEF 回調（SetUnhandledExceptionFilter），OS 僅追蹤最新註冊的回調。CLR 初始化時會註冊自己的 UEF，但鏈結極易斷裂：

情況 A：托管碼 P/Invoke 呼叫原生組件，該組件在 CLR 之後註冊 UEF 且不呼叫前一個回調 → CLR UEF 不被觸發。
情況 B：原生組件先註冊 UEF，再載入 CLR → CLR 註冊時保存原始回調，但若原始 UEF 回傳「已處理」，CLR 會放棄處理。

若發現 CLR 未處理例外處理未啟動，極大機率是上述兩種情況之一。

AppDomain.UnhandledException 事件通知
事件永遠在預設 AppDomain 引發；若執行緒在非預設 AppDomain 建立，也會送達該 AppDomain。這是記錄錯誤根因的最後機會，因為進程即將終止。
範例：
```
AppDomain.CurrentDomain.UnhandledException += (s, e) => {
    var ex = (Exception)e.ExceptionObject;
    Log.Fatal("未處理例外: " + ex.ToString());
};
```
收集 Watson 儲存桶資訊並寫入事件日誌
CLR 收集 9 項資訊（模組名稱、IL Offset、MethodDef、例外類型等），形成 Watson Bucket 寫入應用程式事件日誌，供事後分析與歸類。
關鍵點：儲存桶對應的是最後被擲出且未處理的托管例外。若例外被重新擲出、包裝為 InnerException、或跨 AppDomain 封送，IL Offset 會指向重新擲出點或呼叫端框架。
顯示錯誤對話框與控制台堆疊追蹤
彈出「偵錯/關閉」對話框；若為嚴重例外（StackOverflowException、OutOfMemoryException），僅顯示簡短字串避免遞迴崩潰。最後將控制權交還給呼叫者（OS 或 CLR）。