用 C++ 異常機制優雅替代 exit()：錯誤處理現代化指南

許多從 C 轉 C++ 的開發者習慣用 exit() 甚至 abort() 粗暴終止程序。隨著項目規模增長、模塊解耦需求上升，這種「一鍵了事」會導致資源洩漏、日誌缺失、無法優雅降級。本文展示如何用 **C++ 異常機制** 系統性替換 exit()，實現分層錯誤處理與資源安全釋放。

為什麼不該用 exit()？

• ❌ 繞過棧展開，**析構函數不被調用** → 鎖未釋放、文件未關閉、內存洩漏；
• ❌ 無法傳遞錯誤上下文，上層調用者不知發生什麼；
• ❌ 難以單元測試：測試框架無法捕獲進程退出；
• ❌ 破壞 RAII 原則，違背現代 C++ 資源管理哲學。

漸進式重構策略

階段 1：最小改動——直接拋出整數錯誤碼

// 原代碼
void ReadBytes() {
    if (error) { printf("error!\n"); exit(-1); }
    return nBytesRead;
}

// 改為
void ReadBytes() {
    if (error) throw -1;  // 拋出 int 異常
    return nBytesRead;
}

在主入口或模塊邊界捕獲：

int main() {
    try {
        ProcessMail();
    } catch (int errCode) {
        logError(errCode);
        return errCode;  // 返回碼代替 exit
    }
}

階段 2：引入異常類別體系（推薦）

class AppException : public std::exception {
public:
    AppException(int code, std::string msg) : m_code(code), m_msg(std::move(msg)) {}
    int code() const noexcept { return m_code; }
    const char* what() const noexcept override { return m_msg.c_str(); }
private:
    int m_code;
    std::string m_msg;
};

// 業務代碼
void ReadBytes() {
    if (error) throw AppException(ERR_IO, "ReadBytes failed: " + getSystemErrorMsg());
}

階段 3：分層處理與恢復策略

void ProcessMail() {
    try {
        init();
        while (!shutdown) {
            try {
                ReadMail();
            } catch (const AppException& e) {
                if (e.code() == ERR_TRANSIENT) {
                    retry();  // 可恢復錯誤：重試
                } else {
                    throw;    // 不可恢復：向上拋出
                }
            }
        }
    } catch (const AppException& e) {
        logFatal(e);
        throw;  // 繼續拋給主函數決定是否退出
    }
}

關鍵優勢對比

避坑提醒

• ⚠️ **不要在析構函數中拋出異常**（雙重異常導致 std::terminate）；
• ⚠️ 異常類應繼承 std::exception，便於標準捕獲；
• ⚠️ 性能敏感熱路徑慎用異常（現代編譯器零開銷模型下非熱路徑無感）；
• ⚠️ 跨 DLL/動態庫邊界拋出異常需確保同一 CRT/ABI，否則改用錯誤碼或 std::error_code。

將 exit() 替換為結構化異常處理，不僅是語法遷移，更是**錯誤處理哲學的升級**：從「崩潰即正義」轉向「可控、可觀測、可恢復」。