C++ 異常處理與錯誤管理實戰經驗談

為何選擇異常而非回傳碼？

回傳碼迫使呼叫端充滿 if 判斷，增加分支複雜度：

• 程式碼品質下降：條件判斷錯誤率約為其他陳述式 10 倍。
• 測試成本增加：每個分支皆需測試覆蓋。
• 開發成本上升：控制流程複雜化除錯困難。

try/catch/throw 產生較少 Bug、較低開發成本、更快上市的程式碼。

建構函式失敗怎麼辦？

建構函式無回傳值，**拋出異常是標記失敗的最佳方式**。

若禁用異常，替代方案：進入「殭屍狀態」（設定內部旗標），提供 IsValid() 查詢函式。但此法不雅且易誤用。

解構函式失敗怎麼辦？

絕不在解構函式拋出異常！

若在堆疊展開過程中解構函式再拋出異常，C++ 執行期無法決定處理哪個異常，直接呼叫 terminate() 結束程式。唯一安全做法：記錄錯誤日誌，吞下異常或呼叫 abort()。

建構函式拋出異常時的資源管理

若建構函式拋出異常，物件解構函式**不會**被呼叫。已取得資源（記憶體、檔案、訊號量）必須由成員物件自行清理 → **RAII (Resource Acquisition Is Initialization)**。

class MyClass {
    std::auto_ptr<Resource> res_;  // 智慧指標管理資源
public:
    MyClass() : res_(new Resource) { /* 若後續拋出異常，res_ 自動釋放 */ }
};

標準庫 std::auto_ptr (C++11 後用 unique_ptr) 即此模式範例。

字串處理避免記憶體洩漏

使用 char* 手動管理記憶體極易出錯，需配合 try/catch 確保釋放。改用 std::string 自動管理記憶體：

void userCode(const std::string& s1, const std::string& s2) {
    std::string copy = s1;  // 複製
    copy += s2;             // 追加，自動擴容
    // 無需 try/catch，異常拋出時 string 自動釋放記憶體
}

優勢： 程式碼從 12 行減為 2 行，零記憶體洩漏風險，效能不遜手工管理。

核心原則總結

1. 優先使用異常處理錯誤，簡化控制流程。
2. 建構函式失敗拋出異常；解構函式**絕不**拋出異常。
3. 所有資源封裝於 RAII 物件中（智慧指標、容器、string、鎖守衛）。
4. 拒絕手動 new/delete、char* 字串操作，擁抱標準庫。