C++ 异常处理：异常安全与 RAII

程序运行过程中遭遇文件锁死、内存耗尽或网络断开时，C++ 会抛出异常。若不进行拦截处理，控制流会直接跳出当前函数作用域，导致已申请的内存或文件句柄永久泄漏。掌握 RAII（资源获取即初始化，即让对象全权绑定资源生命周期）与异常安全设计模式，是编写零泄漏 C++ 系统的标准实践。

阶段一：确定异常防护等级

1. 评估业务逻辑对数据一致性的容忍度，决定底层代码需要达到的防护强度。

2. 设定所有新开发模块的默认底线为基本保障，涉及资金或核心配置的操作强制要求强保障。

阶段二：构建 RAII 资源管理类

1. 声明资源包装类框架，明确独占资源的所有权语义。

   
   #include <cstdio>
   #include <string>
   #include <utility>
   #include <stdexcept>

class DbConnection {
public:
explicit DbConnection(const std::string& conn_str);
~DbConnection() noexcept;
// 禁止拷贝，避免同一物理连接被重复关闭引发段错误
DbConnection(const DbConnection&) = delete;
DbConnection& operator=(const DbConnection&) = delete;
// 允许移动，支持资源在标准容器或智能指针间安全转移
DbConnection(DbConnection&& other) noexcept;
DbConnection& operator=(DbConnection&& other) noexcept;

void execute_query(const std::string& sql);

private:
std::FILE* conn_ptr = nullptr;
};

2. **实现**构造函数，将底层资源申请动作与对象构造生命周期严格绑定。
3. **检查**系统调用返回值，若连接建立失败则立即抛出标准异常对象。
```cpp
DbConnection::DbConnection(const std::string& conn_str) {
    conn_ptr = std::fopen(conn_str.c_str(), "rw");
    if (!conn_ptr) {
        throw std::runtime_error("数据库连接建立失败");
    }
}

4. 编写析构函数并强制标记为 noexcept，防止异常展开流程被二次中断导致程序直接调用 std::terminate。

   DbConnection::~DbConnection() noexcept {
    if (conn_ptr) {
        std::fclose(conn_ptr);
        conn_ptr = nullptr;
    }
   }

5. 填充移动构造与移动赋值函数，使用 std::exchange 接管原始指针并清空源对象状态。

   
   DbConnection::DbConnection(DbConnection&& other) noexcept 
    : conn_ptr(std::exchange(other.conn_ptr, nullptr)) {}

DbConnection& DbConnection::operator=(DbConnection&& other) noexcept {
if (this != &other) {
std::fclose(conn_ptr);
conn_ptr = std::exchange(other.conn_ptr, nullptr);
}
return *this;
}

6. **调用** `std::make_unique<DbConnection>("db_path")` **替代**裸 `new` 分配，利用编译器自动管理栈对象析构顺序。

---

## 阶段三：实施强异常安全的提交策略

1. **创建**当前业务数据结构的完整深拷贝副本，作为隔离修改的临时工作区。
2. **执行**所有可能分配内存、访问网络或修改索引的危险操作，全部限定作用于临时副本内部。
3. **验证**临时对象内部校验和或状态标志，确认数据结构未被异常破坏。
4. **调用**标记为 `noexcept` 的交换函数，将当前对象与临时副本的底层指针进行原子化替换。
```cpp
class UserCache {
public:
    void update_profile(const std::string& uid, const Profile& p) {
        // 强保障核心：在独立副本上推进高风险操作
        UserCache temp_copy = *this;

        // 此处可能触发 std::bad_alloc 导致异常
        temp_copy.records[uid] = p; 

        // 提交步骤绝不抛出，保证要么全量生效，要么完全回滚
        swap(temp_copy);
    }
    void swap(UserCache& other) noexcept {
        using std::swap;
        swap(records, other.records);
    }
private:
    std::unordered_map<std::string, Profile> records;
};

5. 依赖临时副本 temp_copy 的作用域结束机制，让编译器自动调用其析构函数清理失败分支残留的内存块与临时锁。

阶段四：验证异常路径与内存状态

1. 注入强制抛出桩代码，在核心逻辑入口处添加 if (test_trigger) throw std::logic_error("模拟中断"); 以阻断正常执行流。
2. 配置编译器内存检测参数，终端执行 export CXXFLAGS="-fsanitize=address,leak -g -O1" 指令准备构建环境。
3. 运行包含异常触发路径的集成测试用例，观察控制台标准错误流输出。
4. 扫描 AddressSanitizer 检测报告，确认直接泄漏字节数与泄漏对象数均为 0。
5. 核对核心容器状态断言，确保捕获异常并清理后，业务对象的 size() 与 empty() 返回值严格等于调用前的初始值。