C++异常抛出模式：别让throw()和noexcept变成你代码里的“装饰品”

写C++时，你有没有遇到过这种场景：函数明明标了throw()，结果运行时还是崩在了没预料到的异常上？或者改用noexcept后，程序突然在某个深夜安静地调用std::terminate，连个堆栈都没留下？不是语法写错了，是异常抛出模式被当成了可有可无的注释——而它本该是你和编译器之间一份严肃的契约。

C++里控制异常抛出行为的机制，从来就不是“要不要抛异常”的二选一，而是“谁来负责兜底、何时触发终止、编译器能帮你优化到哪一步”的三重权衡。我们得从实际问题出发，把throw()、noexcept(true)、noexcept(false)和noexcept(expr)真正用起来。

先说一个容易被忽略的事实：throw()在C++11中已被弃用但未删除，它语义模糊（编译器不强制检查，运行时才可能触发std::unexpected），且和noexcept混用会引发未定义行为。如果你还在项目里看到void foo() throw(int);，别急着删——先查查它是不是被模板元编程或旧版Boost间接依赖着。稳妥做法是：新代码一律用noexcept，存量代码逐步替换，替换前务必确认调用链中所有间接依赖是否已适配。

noexcept真正发力的地方，在于它不只是声明，更是编译器优化的开关。比如移动构造函数标记为noexcept，std::vector在扩容时才敢放心调用移动而非拷贝——这直接影响性能。但很多人卡在第一步：怎么判断一个函数到底能不能标noexcept？
答案不是靠猜，而是看它直接调用的所有函数是否都noexcept，以及自己是否显式抛出、是否可能触发隐式异常（比如new失败抛std::bad_alloc、dynamic_cast失败抛std::bad_cast）。举个具体例子：

struct Buffer {
    std::vector<char> data_;
    explicit Buffer(size_t n) : data_(n) {} // 构造vector可能抛bad_alloc
    Buffer(Buffer&& other) noexcept : data_(std::move(other.data_)) {}
};

这里移动构造函数标noexcept是安全的，因为std::vector的移动构造本身是noexcept（C++11起保证）。但如果你自己写了data_.reserve(n)，就得重新评估——reserve可能抛异常，那这个移动构造就不能标noexcept。

更实用的技巧是：用noexcept(expr)做条件声明。比如封装一个可能失败的系统调用：

bool try_mmap(size_t size) noexcept(noexcept(mmap(nullptr, size, PROT_READ, MAP_PRIVATE, -1, 0))) {
    return mmap(...) != MAP_FAILED;
}

括号里的noexcept(...)是编译期表达式，编译器会真去检查mmap调用是否可能抛异常（实际中mmap不抛，所以整个函数就是noexcept(true)）。这种写法避免了硬编码，也防止未来接口变更导致声明失效。

还有一类高频陷阱：析构函数默认是noexcept(true)。这意味着如果你在析构函数里调用了可能抛异常的函数（比如fclose()失败、std::thread::join()被调用两次），程序会直接终止。解决方法不是给析构函数加noexcept(false)（C++标准禁止这么做），而是在析构函数内部用try/catch吞掉异常，或确保所有操作都是异常安全的。例如：

~FileHandle() {
    if (fd_ != -1) {
        try { close(fd_); } // close系统调用不抛C++异常，但封装层可能throw
        catch (...) { /* 记录日志，不传播 */ }
    }
}

最后说个实战建议：别在接口设计初期就盲目加noexcept。先让功能跑通，用静态分析工具（如Clang’s -Wexceptions）或ASan+UBSan组合跑几轮压力测试，观察哪些函数实际从未抛异常，再逐个补上noexcept。这样既避免过度承诺，又能获得真实收益。

异常抛出模式不是装饰性的语法糖，它是编译器理解你意图的唯一途径，也是你在资源管理、性能优化和错误恢复之间划下的责任边界。下次写完一个函数，别只问“它能不能编译”，多问一句：“如果它标了noexcept，我敢不敢让它进生产环境的热路径？”

这个问题的答案，比任何语法细节都重要。