《More Effective C++：35个改善编程与设计的有效方法》
读书笔记：以by reference方式捕捉exceptions
在C++异常处理中，catch 子句捕获异常对象的方式有三种：按指针（by pointer） 、按值（by value） 和 按引用（by reference） 。看似简单的选择，却暗藏诸多陷阱。本文将剖析三种方式的优劣，揭示为何 按引用捕获 是最优解。
一、按指针捕获：风险与困境并存
理论上，按指针捕获异常（catch (Exception*)）无需复制对象，似乎高效。但实际应用中，它存在致命缺陷：
1. 生命周期的"定时炸弹"
如果抛出局部对象的指针 （如 throw &localEx;），函数执行完毕后局部对象会被销毁，捕获到的指针将指向已释放的内存，导致未定义行为（程序崩溃或更诡异的错误）。
即使改用静态/全局对象，虽然避免了销毁问题，但开发者容易遗忘"对象必须长期有效"的约束，维护成本极高。
2. 内存管理的两难
若抛出堆对象 （如 throw new Exception;），捕获后需手动 delete 释放内存。但问题在于：
- 无法判断所有抛出的指针都指向堆对象（比如全局对象的指针），盲目
delete会导致未定义行为； - 若忘记
delete，则造成内存泄漏。
这种"删还是不删"的困境，让按指针捕获变得极不可靠。
3. 标准异常的不兼容
C++标准库的异常（如 bad_alloc、bad_cast 等）都是对象而非指针。若用指针捕获，无法匹配这些标准异常，迫使代码额外处理指针逻辑，增加复杂度。
二、按值捕获：被切割的多态性
按值捕获（catch (Exception ex)）看似简单，却会破坏多态性，还带来性能开销：
1. 对象切割（Slicing）的灾难
当抛出派生类异常 （如 ValidationError 继承自 runtime_error），按值捕获时，编译器会将派生类对象切片 为基类（Exception）对象------派生类的独有成员和虚函数重写会被"切掉"。
例如：
cpp
class ValidationError : public runtime_error {
public:
const char* what() const noexcept override {
return "Validation failed!";
}
};
void someFunction() {
throw ValidationError(); // 抛出派生类异常
}
void doSomething() {
try {
someFunction();
} catch (exception ex) { // 按值捕获，发生切割
cerr << ex.what(); // 调用基类exception::what()，而非派生类的实现
}
}结果会输出基类的默认信息，而非派生类的"Validation failed!"，完全违背多态设计的初衷。
2. 额外的复制开销
异常对象抛出时会被复制一次 （存入异常存储区），按值捕获时会再复制一次 （从存储区复制到 catch 的参数）。两次复制不仅消耗性能（条款12提及），还可能引发复杂的资源管理问题。
三、按引用捕获：完美解决痛点
按引用捕获（catch (Exception& ex)）则完美规避了上述问题，成为最优选择：
1. 安全的生命周期
异常对象会被编译器妥善管理（存储在异常存储区，生命周期持续到异常处理完成），引用直接绑定该对象，无需担心悬空或销毁问题。
2. 完整的多态性
引用会保留派生类的动态类型，虚函数调用时会正确调度到派生类的实现。修改上面的例子：
cpp
catch (exception& ex) { // 按引用捕获
cerr << ex.what(); // 调用ValidationError::what()，符合预期
}3. 更低的性能开销
仅在抛出时复制一次（到异常存储区），捕获时通过引用访问，无额外复制，性能更优（条款12的优化）。
4. 天然兼容标准异常
标准异常以对象形式抛出，按引用捕获可自然匹配，无需处理指针的复杂逻辑，代码更简洁。
总结：为什么选按引用？
- ✅ 避免指针的生命周期陷阱 和内存管理困境；
- ✅ 解决值捕获的对象切割 和重复复制问题；
- ✅ 完美支持多态，兼容标准异常体系。
简言之，按引用捕获异常 是C++异常处理的"最优解"，兼顾正确性、性能和代码简洁性。在实际开发中，应始终优先选择 catch (Exception& ex) 的形式！
（本文内容参考《Effective C++》条款13，深入分析异常捕获的设计考量。）