C++异常处理核心：RAII、栈展开与异常安全实战

直接拿 try/catch 来套 C++ 异常处理，是很多项目走到后面发现代码“能跑但不敢改”的根源。异常处理从来不是某个括号里怎么写的问题，而是程序在一个错误已经发生、调用栈还在继续往上退时，怎样安全地收尾和恢复的问题。

我见过不少写过一两年 C++ 的人，提到异常处理就是“try 包住可能出错的代码，catch 里记个日志，程序继续跑”。这个印象不能说错，但实在太薄了。真正把异常当作核心错误传播机制写过一段时间后，你会发现最重要的问题根本不是“异常怎么 catch”，而是“一场已经发生的失败，在代码里应该以什么样的路径扩散、由谁接管、如何保证中间对象的资源不泄漏”。围绕这几个问题展开，才能说真正理解 C++ 异常处理。

1. 先搞清楚异常机制到底解决了什么问题

C++ 诞生这么多年，错误处理仍然是一个比想象中更难的话题。很多老项目里最常见的方式是返回值约定：成功返回 0，失败返回 -1，再配合一个全局错误码。这种思路写起来非常直接，但它有一个致命的问题：如果调用链很深，中间层函数不认识这个错误，那就必须在每一层都写一套“传下去”的逻辑。少写一个分支，错误就会被静默吞掉，最后表现出一个极其难定位的诡异状态。

1.1 返回值风格的多资源清理困境

看一个非常典型的场景。我要往文件里写一段数据，写完还要顺带写元信息，中间任何一步失败了都不能当成成功返回：

cpp复制bool writeBuffer(const Data& data, const char* path) {
    FILE* fp = fopen(path, "wb");
    if (!fp) {
        return false;
    }
    if (fwrite(data.ptr, data.size, 1, fp) != 1) {
        fclose(fp);
        return false;
    }
    if (data.needMeta && !writeMeta(fp, data.meta)) {
        fclose(fp);
        return false;
    }
    fclose(fp);
    return true;
}

这段代码看似没什么毛病，但仔细看会发现两个隐患。第一，每个错误分支都必须记得 fclose(fp)，以后只要增加一个新的失败分支，就很容易漏掉 fclose，形成文件句柄泄漏。第二，函数返回值是 bool，调用方如果只写：

cpp复制writeBuffer(data, "/tmp/a.bin");

完全不检查返回值，这个失败就被无声地吞掉了。返回值风格对“调用方是否处理错误”完全没有强制力，编译器不会因为你漏掉 if (!ok) 发出任何警告。

C++ 异常机制换了一种思路：允许函数在失败时主动中断当前执行路径，把错误信息打包成一个异常对象，沿着调用链往上寻找能处理它的 catch。中间层不需要写传给上层的代码，也不需要在每个分支里准备 return false。

1.2 用异常处理时，资源管理方式必须跟着变

但是，如果只把 return false 换成 throw，代码并不会自动变好。同样是打开文件写数据的例子，如果不做任何资源管理，直接这样写：

cpp复制void writeBuffer(const Data& data, const char* path) {
    FILE* fp = fopen(path, "wb");
    if (!fp) {
        throw std::runtime_error("cannot open file");
    }
    fwrite(data.ptr, data.size, 1, fp);  // 假设这里抛异常
    fclose(fp);
}

中间 fwrite 一旦抛异常，后面那行 fclose(fp) 根本执行不到，文件句柄就泄漏了。异常机制把错误传播路径变得很干净，但它同时把资源释放的职责推给了局部对象的析构函数。换句话说，想在 C++ 里用好异常，必须先接受一个前提：资源不能靠函数末尾的统一释放，而要靠 RAII 对象在栈展开时自动析构。

这也是我把这部分放在第一位的原因。很多初学异常的文章一上来就讲 try/catch 语法，但真正让你代码不泄漏的是下面这种结构：

cpp复制void writeBuffer(const Data& data, const char* path) {
    std::ofstream out(path, std::ios::binary);
    if (!out) {
        throw std::runtime_error("cannot open file");
    }
    out.write(data.ptr, data.size);   // 抛异常也无所谓
    if (data.needMeta) {
        writeMeta(out, data.meta);    // 抛异常也无所谓
    }
}

std::ofstream 的析构函数会自动关闭文件句柄。无论中途哪一行抛出，局部对象都会在栈展开时被析构，文件被关闭，资源被释放。异常处理和 RAII 是绑在一起的，只学前者不学后者，代码一定是破的。

2. 抛出异常之后，调用栈上到底发生了什么

很多资料喜欢把异常简化成“从 throw 跳到 catch”，这个比喻很容易误导人。C++ 异常处理并不会像 goto 那样直接从 throw 跳到 catch，它要先执行一个被称为栈展开的完整过程。

2.1 栈展开的真正顺序

看下面这段代码：

cpp复制void third() {
    throw std::runtime_error("fail");
}

void second() {
    std::string localString = "world";
    third();
    // 这行不会执行
}

void first() {
    std::unique_ptr<int> p = std::make_unique<int>(1);
    second();
}

int main() {
    try {
        first();
    } catch (const std::exception& e) {
        std::cout << e.what() << '\n';
    }
}

当 third() 里抛出异常后，编译器会在当前调用栈中一级一级往上找匹配的 catch。在找的过程中，每退出一个函数，这个函数内已经构造完成的局部对象都会被逆序析构。second() 里的 localString 会先销毁，然后函数栈帧退出，接着 first() 里的 p 再销毁，最后异常才到达 main() 的 catch 块。

这个机制的好处是，你不需要记得在函数末尾释放资源，局部对象生命周期结束了，析构函数就会被调用。坏处是，它要求所有资源必须放在析构函数不会抛异常的局部对象里。如果你在函数内部用裸 new 创建了资源，并且这个资源只靠一个裸指针保存，栈展开时编译器根本不知道该去释放它，于是泄漏就发生了。

所以我把这句话写在这里：栈展开只能自动管理“有析构函数的局部对象”，管理不了裸指针，也管理不了所有保存在堆上但没有任何 RAII 包装的资源。看别人写的异常安全代码时，第一件事就是看有没有裸指针在函数体内飞来飞去。

2.2 析构函数往外抛异常，程序离 terminate 就不远了

这也是 C++ 异常处理和 Java、Python 差异比较大的一点。Java 的析构概念非常弱，C++ 则把资源释放押注在析构函数上。如果析构函数本身又把异常抛出去，在栈展开期间就会同时存在两个异常，这时语言运行时的选择不是让你继续 catch，而是直接调用 std::terminate 终止程序。

C++11 之后，析构函数默认是 noexcept。这意味着你写：

cpp复制class Timer {
public:
    ~Timer() {
        // 里面一旦 throw
    }
};

这个 throw 在大多数情况下不是能被 catch 的普通异常，而是直接触发 terminate 的致命错误。有些编译器会给出 warning，但警告不是约束，代码一旦跑到那个分支，程序就没了。

我在实际项目里的处理原则有两条。第一，析构函数只做不抛出的收尾动作，比如关文件、释放内存、归还互斥锁，这些操作本身要么不失败，要么失败也无所谓。第二，如果某个清理操作确实可能失败，而且失败信息很重要，不要在析构函数里直接抛，把失败记录到日志，或者放入一个错误队列，等业务代码稍后主动查询。析构函数抛出异常，是 C++ 异常处理里最容易被高估、也最危险的用法。

2.3 构造函数里抛异常，析构函数不一定执行

还有一个经常被忽略的点：C++ 只会对“完成构造”的对象调用析构函数。如果构造函数执行到一半抛出异常，这个对象的析构函数不会被调用，因为语言认为这个对象从来没有完整地活过。

这个规则非常隐蔽，看代码会更清楚：

cpp复制class Config {
public:
    Config() {
        buffer_ = new char[1024];
        LoadMore();   // 这里抛异常
    }
    ~Config() {
        delete[] buffer_;
    }
private:
    char* buffer_ = nullptr;
};

构造函数执行顺序是：成员变量先初始化，再进入构造函数体。上面例子中 buffer_ 已经在构造体里分配了内存，随后 LoadMore() 抛出异常，对象构造失败，析构函数不会被调用，那 1024 字节就永久泄漏了。

解决办法不是靠 try/catch 包住构造函数体，而是尽量不要让构造函数管理裸资源。把 char* buffer_ 换成 std::vector<char> buffer_，或者 std::unique_ptr<char[]>，问题就消失了。因为成员变量在构造函数体执行之前已经初始化完成，如果构造函数体抛出，已经构造完成的成员对象会被自动逆序析构。异常机制给了你一条规则：成员变量用 RAII 类型，构造函数体里随便抛，资源不会泄漏。

3. 异常安全等级，决定代码是真的能扛错，还是仅仅没报错

很多 C++ 程序员能把语法写顺，但对“异常安全”这个词没有概念。异常安全不是说“抛异常后程序没崩溃”，而是说“抛异常后你的对象和程序状态是否还是有效的”。这句话值得品很久。

3.1 先建立三个基本级别的判断标准

业内习惯把迭代器的异常安全保证分成三个级别。最基本的级别叫基本保证，意思是抛出异常后对象仍然满足类内部的不变量，对象处于合法但状态不确定的状态，不会泄漏资源。强保证的意思是抛出异常后，对象和操作前完全一样，相当于这次操作没有发生过。最高级别是 nothrow guarantee，即这个操作永远不会抛异常，比如 int 赋值、关闭普通文件描述符这类操作。

举个最经典的例子，标准库 std::vector::push_back 的内存扩容操作是强保证的：如果扩容中途抛异常，vector 会保持原来的元素，不会出现一半新数据一半旧数据。这个保证不是天然来的，而是通过先构造新内存、成功后再交换指针来实现的。如果你的自定义类也想像 vector 一样提供强保证，一个非常有效的实现套路是 copy-and-swap。

3.2 用 copy-and-swap 让强保证自然成立

假设要维护一个带内部缓冲区的类型：

cpp复制class Buffer {
public:
    Buffer& operator=(const Buffer& other) {
        if (this == &other) {
            return *this;
        }
        // 先拷贝一份临时对象
        Buffer temp(other);
        // 再交换内部状态，swap 通常不抛异常
        swap(temp);
        return *this;
    }

    void swap(Buffer& other) noexcept {
        data_.swap(other.data_);
    }

private:
    std::vector<char> data_;
};

赋值运算符中先做 Buffer temp(other)，如果拷贝构造抛异常，*this 完全没被改动，强保证自动成立。只有临时对象构造成功，才把内部状态交换过来，而 std::vector::swap 明确是 noexcept 的。这套写法让我在实现复杂对象时省掉了很多心智负担：不要在赋值函数里一个成员一个成员地赋值，先构造临时体，再统一交换。

有了强保证意识之后，写代码时就会主动避免“先改这个成员，再改那个成员”的写法。因为如果第一个成员改成功了，第二个成员操作时抛出异常，对象就处在一种自相矛盾的中间状态。这时候即便没有资源泄漏，也只能满足基本保证，使用方无法判断数据到底是什么样。

3.3 异常安全不能靠事后补，要靠类型设计前置

我在代码评审里经常看到有人问：“这里可能抛异常，我在外面 try/catch 一下是不是就安全了？” 答案往往是否定的。try/catch 只能处理已经抛出来的异常，不能解决异常抛出来之后对象内部状态已经被改乱的问题。

真正稳妥的做法是在类型设计阶段就规划好边界。一个操作要么成功完成，要么在失败时把对象恢复到原状。那些需要多个内部成员同步更新才能完成的操作，尽量把计算和更新拆开，先在临时对象上做所有可能失败的计算，全部成功后再一次性提交到正式对象里。这就是把事务思想借鉴到普通类设计上。

你可以不用把每个函数都做成强保证，但至少要能说出你的类提供哪种保证。如果一个类连基本保证都做不到，那么用起来就需要调用方在每一个操作外手工维护状态，错误处理会退回成原始的手工判断风格，异常机制的价值就大打折扣了。

4. noexcept、异常规格和编译器规则里的硬边界

异常处理不是只有 try/catch 和栈展开，C++ 还通过异常规格给函数加了一层合约。noexcept 从 C++11 进入标准库后，已经成为容器优化和代码正确性都不能绕过的一部分。

4.1 noexcept 不只是“我不打算抛出”的注释

很多初学者以为给函数加 noexcept 只是告诉编译器“我这个函数不会抛异常，你不用担心”。实际上，这个标记承担着比注释重得多的责任。

最典型的例子是标准库容器扩容。std::vector 在容量不足时会把已有元素迁移到新内存。迁移方式取决于元素的移动构造函数是否标了 noexcept：如果标了，vector 可以放心地移动每个元素；如果没有标，vector 为了保证异常安全，会退化为拷贝每个元素。当元素类型是只可移动不可拷贝时，移动构造函数如果不标 noexcept，vector 扩容甚至可能编译失败。

这里要小心：noexcept 不是嘴上说说，而是一个运行时契约。如果一个标了 noexcept 的函数内部真的抛出了异常，程序不会让异常继续传播，而是立刻调用 std::terminate。也就是说，它把一个可捕获、可恢复的运行期错误，变成了一个不可恢复的进程终止问题。

所以正确姿势是只在“确定不会抛”或者“如果抛了也不该被恢复”的场景下使用 noexcept。移动构造函数、移动赋值运算符、析构函数、swap 函数是值得认真考虑加 noexcept 的地方。那些内部可能做内存分配、可能做用户输入解析、可能打开外部资源的函数，不要为了看起来高效而随意标 noexcept。

4.2 异常规格的历史版本很容易把人绕晕

老项目里偶尔能看到这种写法：

cpp复制void oldFunction() throw(std::exception);

这是 C++98/03 时代的动态异常规格，意思是这个函数“可能抛出 std::exception”。如果运行期间抛出的类型不在列表中，程序会调用 std::unexpected。这套机制从设计上就不讨喜，给运行时增加了不少额外开销，C++17 已经把它移除了。如果你在看老代码时遇到这种语法，思想上应该把它看成“这个函数声明了自己的异常边界”，而不是真的要依赖运行时去检查类型。

C++11 之后推荐的是 noexcept 或 noexcept(true)、noexcept(false) 这种写法。区别在于 noexcept 是编译期规格，不参与运行时检查，类型更干净，也更适合编译器优化。C++17 又把 throw() 这种动态规格彻底请出了舞台。今天写新代码，要么不写异常规格，要么写 noexcept，不要再用旧式 throw(SomeType) 去约束函数。

4.3 异常的成本：不抛几乎无感，抛出后不便宜

早年常听到“C++ 异常很慢”的说法，这个说法需要拆开看。现代主流编译器的调用约定大多基于零成本异常模型，代码在正常路径上不执行任何异常相关判断，也不维护运行时状态表去记录某个局部对象要不要析构，所以“不抛异常”的路径性能是非常好的。

真正的成本集中在抛出和捕获那一刻。抛出异常时，运行时需要构建异常对象，遍历调用栈找到合适的 catch，还要沿途执行析构函数。这个过程通常比一次简单的函数返回慢上不少。因此，异常不适合用在“循环内部每帧都可能触发”的热路径上，更适合用在真正异常的、低频的失败场景中。C++ 社区里对性能敏感库经常采用的办法是：内部不使用异常，但在对外接口边界把错误转换成异常抛出，让调用方保持统一风格。

4.4 跨线程传递异常：std::exception_ptr

很多人没有意识到，异常对象不能直接像普通值那样丢给另一个线程任意使用。假设一个工作线程在某个任务中抛出了异常，主线程想要感知到这个失败，简单的做法是重新抛出一个全新的异常，但这样会丢失原异常的类型和上下文。标准库提供了 std::exception_ptr 来处理跨线程异常传递。

cpp复制std::exception_ptr pending;

std::thread worker([&]{
    try {
        DoHeavyWork();
    } catch (...) {
        pending = std::current_exception();
    }
});

worker.join();

if (pending) {
    std::rethrow_exception(pending);
}

工作线程捕获异常后，用 std::current_exception() 取得一个指向当前异常对象的共享指针，存到 pending 里。主线程在合适的时机用 std::rethrow_exception(pending) 重新抛出这个异常，再走正常的 catch 流程。这个机制保证了异常类型不会被截断，也避免了自己手工传输错误码丢失细节的问题。我在做线程池和异步任务框架时经常依赖这个特性，比拿一个 int 错误码回来再查表要可靠得多。

5. 实际工程中特别值得注意的异常处理细节

教科书上的语法大家都会，真正拉开代码质量差距的往往是一些看起来很小的细节。这些细节我基本都在代码评审里亲自拦过、改过，值得专门记一笔。

5.1 捕获时尽量用 const 引用

最常见的习惯是把 catch 参数写成值类型：

cpp复制try {
    // ...
} catch (std::exception e) {
    // ...
}

这会在捕获时产生一次异常对象的拷贝。如果异常对象是从 std::exception 派生的某个子类型，值捕获还会遇到对象切割问题，子类信息全丢了。正确写法是：

cpp复制try {
    // ...
} catch (const std::ios_base::failure& e) {
    // 先处理更具体的类型
} catch (const std::exception& e) {
    // 再处理通用异常
}

const std::exception& 是底线。捕获指针类型 catch (std::exception*) 基本是反面教材，因为这会逼着调用方用 throw new 方式抛异常，一方面容易泄漏，另一方面也把异常对象的所有权问题变得非常模糊。C++ 异常对象应当按值抛出、按引用捕获。

5.2 抛出有信息量的对象，而不是裸字符串

我见过有人这样抛异常：

cpp复制throw "create table failed";

这个表达式可以编译，catch 到的类型是 const char*。这种做法的最大问题是所有错误都成了同一种类型，调用方无法针对不同错误走不同的处理分支。比如网络超时可能想重试，权限不足可能想提示用户，这两种错误的处理策略完全不同，如果都用一个字符串，就必须先做字符串解析，再决定怎么办。

更好的习惯是先从 std::exception 派生出自定义异常类，让类型本身携带分类语义：

cpp复制class HttpError : public std::runtime_error {
public:
    HttpError(int code, const std::string& msg)
        : std::runtime_error(msg), code_(code) {}

    int code() const noexcept { return code_; }

private:
    int code_;
};

抛出时这样写：

cpp复制throw HttpError(404, "resource not found");

调用方可以只针对 HttpError 做处理，也可以统一 catch const std::exception& 做兜底。what() 返回的字符串负责给人看，异常类型负责让代码分支识别，两者搭配才是完整的错误信息。

5.3 手写异常处理链时，注意 catch 的排列顺序和重新抛出

catch 分支是按书写顺序从上到下匹配的。所以必须先写最具体的异常类型，后写最通用的 std::exception，最后才写 catch (...)。如果把 catch (const std::exception&) 放在最前面，后面的派生类型分支永远没机会执行，编译器通常会给出 warning，这个 warning 值得认真对待。

重新抛出也要小心。catch 块里写 throw;，什么都不带，意思是将当前正在处理的异常原封不动继续往上抛，对象的类型和原始信息都会被保留。如果写 throw e; 则是把 e 作为新的异常对象抛出去，这不仅多一次拷贝，而且如果 e 是按引用捕获的派生类型，throw e; 抛出的其实是静态类型。所以记住一句话：要重新抛出，直接写裸 throw; 就好，不要在 catch 里再多此一举。

5.4 该 catch 的地方要收敛，别在整个程序入口滥用 try/catch

有些项目习惯在主函数里包一个巨大的 try/catch，所有异常都在这儿落网，然后记一行日志。这种做法比不 catch 好一点，但绝不是异常处理的正确归宿。主入口 catch 只能作为最后兜底，真正应该决定“这个错误该不该恢复”的位置是业务边界，而不是程序边界。

如果一个错误在业务层就能恢复，比如某个临时文件不存在，重新创建后可以继续，那应该在业务层捕获并恢复。如果一个错误已经破坏了不可逆的状态，比如内存分配失败、配置解析失败，继续运行可能造成更大的问题，那就不该盲目 catch，而应该让错误继续向上传播，交给上层决策。好的异常处理代码读起来像一份“错误决策表”，每个模块都知道自己能处理什么、不能处理什么，而不是把整份 try/catch 堆在程序的同一个角落。

5.5 在循环里做部分失败恢复时的正反例

我经常遇到的一种需求是：批量处理一批任务，单个任务失败不能导致整个批次退出，失败记录要被收集，剩下的任务继续处理。这里很容易搞反 catch 的范围。

先看反面写法：

cpp复制try {
    for (const auto& job : jobs) {
        ProcessOne(job);
    }
} catch (const std::exception& e) {
    // 一个任务失败，整个循环直接停掉
}

如果希望单个任务失败后继续，应该把 try/catch 放进循环体，而不是包住整个循环：

cpp复制std::vector<std::pair<Job, std::string>> failedJobs;
for (const auto& job : jobs) {
    try {
        ProcessOne(job);
    } catch (const std::exception& e) {
        failedJobs.emplace_back(job, e.what());
        // 记录失败后继续下一个任务
    }
}

这两种写法本身的差异很好懂，但在真实代码里很多人看都不看就把 try/catch 拖到最外层，结果就是原本可以部分失败的部分成功需求，被统一处理成了所有任务要么全成功、要么全失败。

5.6 构造函数里用 function-try-block 要格外克制

为了捕获构造函数体和成员初始化过程中抛出的异常，C++ 提供了一种 function-try-block 语法：

cpp复制class Config {
public:
    Config(const std::string& path)
    try : parser_(LoadFile(path)) {
        // 构造函数体
    } catch (const std::exception& e) {
        // 这里可以记录日志
        throw;  // 必须重新抛出，否则会被认为构造成功
    }
};

这种写法的用途很窄。它适合在构造函数初始化阶段只需要“记录错误日志然后继续向上抛”的场景。要注意的是，在 catch 块里，如果你选择不重新抛出，编译器会认为构造函数成功完成，而这个对象实际上并没有被完整构造。所以 function-try-block 的 catch 块基本只能做记录和转换，不能真的“吞掉”异常。与其把希望放在这种特殊语法上，不如在构造函数体执行任何可能失败的操作时，就把异常来源用带上下文的类型包起来再抛出。

我个人的观点是：构造函数的异常处理重点不在 catch，而在设计。让构造函数只负责把对象的成员初始化到正确状态，复杂的业务操作放在具名静态方法或工厂函数里。因为一旦某个对象构造到一半想放弃，代码的可读性会急剧下降，维护者很难判断析构函数、成员变量和异常三者之间的关系。

这些细节单独拿出来都不难理解，但把它们组合在一起时，C++ 异常处理才真正显露出威力。我自己在实际项目里最大的体会是：异常处理不是一门“加 try/catch 的语法”，而是一种从类型设计、资源管理到错误策略都要考虑进去的工程习惯。先让对象在异常发生时能自保，再让函数在异常发生时维持正确的状态，最后才谈怎么把异常从 A 点传到 B 点。顺序反了，后面怎么写都别扭。