在C++项目中，异常处理常常被误用或者过度回避。合理的异常设计可以在不牺牲性能的前提下，让错误传递变得清晰且安全。本文从实战角度梳理抛出与捕获异常的正确方式，并结合代码示例说明常见陷阱。
一、C++异常的基本机制
C++异常依赖于栈展开（stack unwinding）机制。当使用throw表达式抛出异常时，运行时会沿调用栈向上寻找匹配的catch块。在此过程中，所有已构造且尚未销毁的局部对象会自动调用析构函数，这一特性是RAII（资源获取即初始化）能够保障资源安全释放的基础。
很多初学者以为异常一定慢，其实在现代编译器下，无异常抛出时的开销极小，主要成本发生在真正抛出异常并栈展开的时刻。因此异常适合处理真正罕见的错误路径，而不应替代常规的逻辑分支判断。
1.1 抛出异常的基本语法
我们可以通过任意类型对象抛出异常，但实践中推荐继承std::exception的标准类型，以便统一捕获与处理。以下示例展示了一个简单的除法函数，在除数为零时抛异常：
#include <stdexcept>
#include <iostream>
double divide(double a, double b) {
if (b == 0.0) {
// 抛出标准异常，携带错误信息
throw std::runtime_error("division by zero");
}
return a / b;
}
int main() {
try {
std::cout << divide(10.0, 0.0) << std::endl;
} catch (const std::exception& e) {
std::cerr << "error: " << e.what() << std::endl;
}
return 0;
}
上述代码使用std::runtime_error，它派生自std::exception，通过what()方法返回描述。捕获时采用const引用，可以避免对象切片并减少拷贝。
如果抛出的是整型或字符串字面量，虽然语法合法，但会让调用方不得不为多种类型写catch，降低代码一致性。因此团队应约定异常类型规范。
二、异常抛出的最佳实践
异常应当用于报告调用方无法在本地恢复的错误，而不是控制正常流程。比如文件打开失败、内存分配失败、网络连接断开等场景适合抛异常；而用户输入格式不对这种可预期情况，用返回值或optional更合适。
另一个关键点是：绝不要在析构函数中抛出异常。若析构函数在进行栈展开时又抛异常，程序会调用std::terminate直接终止。如果析构中操作可能失败，应捕获内部异常并记录，或提供单独的close()方法由用户显式调用。
2.1 使用RAII避免资源泄漏
结合异常机制，RAII是保证安全的核心手段。下面的例子用智能指针管理动态资源，即使函数中间抛异常，资源也会自动释放：
#include <memory>
#include <stdexcept>
void process() {
// 智能指针在作用域结束或异常展开时自动释放
auto data = std::make_unique<int[]>(100);
if (!data) {
throw std::bad_alloc();
}
// 若此处抛异常，data析构自动回收内存
throw std::runtime_error("processing failed");
}
对比手动new/delete，RAII显著降低了在多处返回或异常路径中忘记释放的概率。这也是现代C++鼓励用容器和智能指针替代原始指针的原因。
在接口设计中，如果函数可能抛异常，应在文档或注释中标明异常安全等级，例如基本保证（basic guarantee）或强保证（strong guarantee），方便上层评估风险。
三、异常捕获的实战策略
捕获异常时应遵循从具体到宽泛的顺序。先捕获派生类异常，再捕获基类std::exception，最后可用catch(...)兜住未知错误，但内部通常只做日志后重新抛出或安全退出。
不要使用空的catch块吞掉异常，这会掩盖bug。若某层确实无法处理，应捕获后做必要清理再throw;向上传递，保留原异常类型与信息。
3.1 精准捕获与宽泛捕获的对比
下列表格列出了两种捕获风格的差异：
| 策略 | 写法示例 | 维护成本 | 适用场景 |
|---|---|---|---|
| 精准捕获 | catch(const std::out_of_range& e) | 低，错误定位快 | 明确知道可能错误类型 |
| 宽泛捕获 | catch(const std::exception& e) | 高，需内部判断 | 顶层统一错误处理 |
在底层模块推荐精准抛出、精准捕获；在程序主循环或线程入口处可用宽泛捕获防止崩溃，并记录上下文。
以下示例展示工厂函数中抛异常，调用方按类型分别处理：
#include <stdexcept>
#include <memory>
class Product {
public:
virtual ~Product() = default;
};
std::unique_ptr<Product> create_product(int type) {
if (type == 0) {
throw std::invalid_argument("unsupported type 0");
}
if (type == 1) {
throw std::runtime_error("resource busy");
}
return std::make_unique<Product>();
}
void caller() {
try {
auto p = create_product(1);
} catch (const std::invalid_argument& e) {
// 处理参数错误
} catch (const std::runtime_error& e) {
// 处理运行时错误
}
}
这种写法让错误分类清晰，也避免上层用错误码逐一判断返回值。当产品创建失败原因多样时，异常比整型错误码更具表达力。
四、异常与性能及兼容性的权衡
在性能敏感且确定性要求高的系统（如部分实时控制）中，可关闭异常（编译选项-fno-exceptions），改用错误码。但大多数业务服务程序，开启异常并规范使用，开发效率与安全性收益更大。
另外，在跨模块（如动态库）传递异常时要谨慎，若双方使用的编译期异常表不一致，可能导致catch无法匹配。此时可在边界处捕获并转为错误码或消息返回。
4.1 异常规格的演进
C++11起废弃了throw(type)异常规格，改用noexcept指明函数不抛异常。标注noexcept不仅表达意图，也允许编译器做更多优化，例如移动容器时若元素移动构造为noexcept可避免拷贝回退。
#include <vector>
void swap_safe(std::vector<int>& a, std::vector<int>& b) noexcept {
a.swap(b);
}
对于明确不会失败的操作，加上noexcept是良好的接口契约。但若标了noexcept却内部抛异常，程序会直接终止，因此只在确有把握时使用。
综上所述，C++异常处理并非洪水猛兽。通过标准异常体系、RAII资源管理、合理捕获层级与noexcept标注，可以写出既安全又易维护的错误处理代码。