异常处理

是什么，为什么存在

C++ 异常由异常对象和非局部控制转移组成。throw 表达式创建异常对象，并停止当前正常路径；运行时沿调用链寻找类型兼容的处理器。匹配的 catch 接管控制后，可以恢复、转换失败，或把同一异常继续向外传播。

这种机制把发现失败的位置与决定如何应对的位置分开。解析函数知道输入为何无效，却未必知道应当重试、显示消息还是放弃请求；调用方掌握这项策略。构造函数没有普通返回值可携带错误，因此无法建立对象不变量时，异常尤其自然。

异常适合表示某次操作无法履行其契约，而且当前层不能完成恢复的情况。标准库的边界检查、内存分配、流操作和用户定义的领域操作都可能采用它。你也会在 std::future::get()、插件边界和顶层请求处理器中遇到传播或转换异常的代码。

异常不是所有失败的默认答案。查找不到元素、输入暂时不可用等预期分支通常更适合 std::optional、std::expected、错误码或普通条件判断。接口选择应表达调用方需要处理的结果，而不是把常见分支伪装成意外故障。

工作原理

执行 throw expression; 时，表达式会初始化一个异常对象。该对象的类型参与处理器匹配，并独立于抛出点的局部对象存活。运行时先检查动态包围抛出点的处理器；没有匹配项时，继续向调用方查找。

处理器按源码顺序尝试。相同类型、无歧义的可访问基类以及标准规定的部分指针转换可以匹配；catch (...) 匹配任何异常。因此，派生异常的处理器必须放在基类处理器之前，而兜底处理器必须放在最后。

查找向外推进时会发生 栈展开（stack unwinding） 。已经完成构造的自动对象按构造的逆序销毁。控制流不会返回被跳过的语句，所以清理工作必须绑定到对象析构，而不能依赖函数末尾的一次手动调用。

一次传播可概括为以下步骤：

1. throw 用操作数初始化异常对象。
2. 运行时按处理器出现顺序检查当前动态包围层。
3. 若未匹配，则销毁离开作用域的已构造自动对象。
4. 匹配后，以异常对象初始化 catch 参数并运行处理器。
5. 处理器结束后，异常对象在不再被引用时销毁；裸 throw; 可以在此之前重新传播它。

RAII（Resource Acquisition Is Initialization，资源获取即初始化） 让栈展开成为可靠的清理路径。std::vector、std::string、智能指针、文件流和锁守卫都在析构函数中结束所有权。只要资源已经交给这类对象，后续任何异常都不会绕过它的释放逻辑。

如果异常离开 noexcept 函数，或者传播过程中又有另一个异常逃出析构函数，程序会调用 std::terminate()。没有匹配处理器的异常最终也会终止程序。异常因此不是自动恢复机制；它只把失败交给仍有能力执行策略的边界。

示例

下面三个示例依次展示类型化处理、栈展开与强异常保证。每段程序都以 -std=c++23 -Wall -Wextra -Wpedantic -Werror 在 GCC 13.3.0 上编译并执行，输出来自实际运行。

按类型处理输入错误

parse_age() 区分格式错误与取值范围错误。调用方可以为两类失败给出不同结果，而成功路径只返回年龄。

两个处理器都通过 const 引用接收异常。这避免复制，也保留实际异常类型和 what() 的虚调用行为。这里不需要 catch (const std::exception&)，因为这个边界只承诺处理两类已知错误。

std::stoi() 自己也可能抛出 std::invalid_argument 或 std::out_of_range。本例随后检查 parsed，因为 std::stoi("42years") 会成功解析前缀，而不是自行拒绝尾部字符。完整的输入契约必须由封装函数补齐。

异常类型表达了调用方可区分的失败类别，消息只提供诊断。程序逻辑不应解析 what() 文本；标准库实现、语言环境或以后修改都可能改变消息内容。

观察栈展开与重新抛出

下一段程序在三层调用中创建跟踪对象。服务层记录异常后使用裸 throw;，让外层仍然接收到原来的 std::runtime_error。

#include <iostream>
#include <stdexcept>
#include <string>
#include <utility>

class Trace {
public:
    explicit Trace(std::string name) : name_(std::move(name)) {
        std::cout << "acquire " << name_ << '\n';
    }

    ~Trace() {
        std::cout << "release " << name_ << '\n';
    }

private:
    std::string name_;
};

void read_response() {
    Trace response("response");
    throw std::runtime_error("checksum mismatch");
}

void load_order() {
    Trace transaction("transaction");
    try {
        read_response();
    } catch (const std::exception& error) {
        std::cout << "service logged: " << error.what() << '\n';
        throw;
    }
}

int main() {
    Trace request("request");
    try {
        load_order();
    } catch (const std::runtime_error& error) {
        std::cout << "main caught: " << error.what() << '\n';
    }
}

acquire request
acquire transaction
acquire response
release response
service logged: checksum mismatch
release transaction
main caught: checksum mismatch
release request

response 在进入 load_order() 的处理器前销毁。处理器运行时，transaction 仍在作用域内；裸 throw; 离开该处理器后，它才被销毁。request 位于 main() 的 try 外部，所以一直存活到 main() 正常结束。

这种顺序说明处理器也拥有普通作用域和局部生命周期。记录代码可以读取仍存活的上下文，但不能保存指向即将因重新抛出而销毁对象的引用。错误上下文需要跨层保留时，应复制稳定数据或构造包含上下文的新异常。

把 throw; 写成 throw error; 会从静态类型为 std::exception 的表达式创建新对象，从而发生 对象切片（object slicing） 。裸重新抛出会保留当前异常对象及其动态类型。

提交后再改变可见状态

Ledger::append_batch() 先在临时副本上验证并追加，全部成功后才交换到成员中。失败的批次不会改变调用前可见的账本。

#include <iostream>
#include <stdexcept>
#include <vector>

class Ledger {
public:
    Ledger() : entries_{100} {}

    void append_batch(const std::vector<int>& amounts) {
        auto next = entries_;
        for (int amount : amounts) {
            if (amount < 0) {
                throw std::invalid_argument("amount must be non-negative");
            }
            next.push_back(amount);
        }
        entries_.swap(next);
    }

    void print() const {
        std::cout << "ledger:";
        for (int amount : entries_) {
            std::cout << ' ' << amount;
        }
        std::cout << '\n';
    }

private:
    std::vector<int> entries_;
};

int main() {
    Ledger ledger;
    try {
        ledger.append_batch({20, -5, 30});
    } catch (const std::invalid_argument& error) {
        std::cout << "rejected: " << error.what() << '\n';
    }
    ledger.print();

    ledger.append_batch({20, 30});
    ledger.print();
}

rejected: amount must be non-negative
ledger: 100
ledger: 100 20 30

第一次调用在临时向量已经追加 20 后失败。临时对象随栈展开销毁，成员 entries_ 仍只有 100。第二次调用完成所有可能失败的构造和追加后，才执行不抛异常的 vector::swap()。

这是一种先准备、后提交的强异常保证实现。它的代价包括复制现有向量和额外存储，因此不应机械套用。另一种设计可以先完整验证输入，再直接修改；是否仍有分配等失败点，需要逐条分析。

异常安全描述的是失败后的可观察状态，不是“代码使用了 try”。只有列出每个可能抛出的操作以及它之前已经发生的状态变化，才能证明保证级别。

陷阱

抛指针或按值捕获

修复： 按值抛出完整对象，通过 const 引用捕获。自定义异常通常继承 std::runtime_error 或另一种合适的标准异常，让 what() 和多态处理自然工作；不要让处理器猜测谁负责释放异常指针。

在错误层级吞掉失败

修复： 只在能够恢复、转换为接口结果或终止一个明确工作单元的边界捕获。需要记录后继续传播时使用裸 throw;；转换异常时保留原始上下文，并让调用方知道当前操作仍然失败。

用手动清理对抗非局部跳转

修复： 获取成功后立刻把资源交给 RAII 类型，例如 std::unique_ptr、容器、流或锁守卫。析构函数必须完成无失败的本地清理；需要报告失败的关闭操作可以另设显式成员函数。

修改一半才验证

修复： 在修改前验证所有可验证条件，把可能失败的工作放在临时状态中，并以不抛异常的操作提交。若成本或领域规则只允许基本保证，就明确记录失败后哪些状态仍有效、哪些值未指定。

对 noexcept 作出虚假承诺

修复： 沿完整调用路径检查异常规范，并用 std::is_nothrow_* 类型特征验证泛型操作。无法证明不抛出时就去掉声明；清理路径若必须吸收错误，应在内部捕获并使用不会再抛出的报告通道。

用异常驱动普通循环

修复： 为预期结果使用迭代器边界、布尔值、std::optional、std::expected 或错误码。只有调用无法履行承诺，而且处理策略属于更外层时才抛出异常；选择应基于语义，而不是未经测量的速度口号。

延伸阅读

• C++23 工作草案：异常处理
• C++23 工作草案：处理异常
• C++23 工作草案：构造函数与析构函数
• C++23 工作草案：异常规范
• C++ Core Guidelines：错误处理