程式設計師對錯誤處理的態度分析：從忽略到過度捕獲的平衡之道

前言

觀察大量程式碼後發現，開發者對錯誤處理普遍存在兩極傾向：完全忽略，或過度捕獲卻缺乏實質處理。本文分析這兩種反模式，並提出務實的錯誤處理策略。

反模式一：完全不攔截錯誤

認為程式碼已考慮所有情況，實際上永遠不可能預測所有意外。常見被忽略場景：

• 輸入驗證繞過：鎖定文字方塊、鍵盤攔截，用戶仍可右鍵貼上文字。
• 檔案系統：磁碟空間不足、目錄唯讀、權限不足、路徑含特殊字元、日期格式異常。
• 資源配額：檢查空間足夠，用戶卻受磁碟配額限制。
• 程序中斷：長時間操作中用戶強制關機，重啟後狀態不一致。
• 資料庫約束失效：設定 NOT NULL，資料中仍出現 NULL（匯入、複製、複寫等）。

結論：防禦性程式設計必須假設錯誤會發生。

反模式二：到處攔截卻不處理

在每個程序加上 On Error GoTo / try-catch，僅彈出 MsgBox 或寫入日誌，然後繼續執行或直接返回。問題：

• 錯誤資訊丟失（堆疊追蹤、內部例外）。
• 呼叫端不知操作失敗，導致後續邏輯使用無效資料。
• 資源洩漏（連線、控制代碼未釋放）。
• 掩蓋真正 Bug，延遲發現時間。

核心觀點：錯誤處理 ≠ 錯誤攔截

真正的錯誤處理包含三層次：

1. 預防：輸入驗證、契約式設計（前置/後置條件）、不可變物件、型別安全。
2. 檢測與隔離：在邊界（UI、API、資料存取層）攔截，封裝為領域例外，保留原始堆疊。
3. 恢復或中止：
   • 可恢復：重試、降級、補償交易、使用者友善提示並引導修正。
   • 不可恢復：記錄完整診斷資訊、安全關閉資源、通知監控系統、讓上層決定終止流程。

實務原則

總結

錯誤處理的藝術在於在正確層級攔截、以正確方式恢復或中止。既不盲目樂觀忽略錯誤，也不機械性地到處 try-catch 卻無實質處理。建立分層例外策略，配合契約式設計與資源管理模式，才能構建健壯、可維護的系統。