异常处理与模板结合需关注类型推导与异常安全。模板中异常传播遵循常规规则，但因类型延迟确定，行为可能随实例化类型变化。例如，SafeContainer::push 调用 vector::push_back 可能因 T 构造失败抛出异常，通过 catch(...) 捕获并重新抛出，确保异常向上传播。现代 C++ 推荐使用 noexcept 规范提升性能与安全性，尤其在模板函数中应采用条件 noexcept，如 swap 函数基于 std::is_nothrow_move_constructible 和 std::is_nothrow_move_assignable 判断是否标记 noexcept，避免过时的动态异常规范。异常安全设计需保证资源不泄漏，推荐使用 RAII 和智能指针，在构造函数中确保异常发生时资源自动释放。强异常安全可通过“拷贝再交换”实现，如 ValueHolder 的赋值操作符以传值方式复制对象，再通过 noexcept 的 swap 交换数据，确保操作要么成功要么不影响原状态。析构函数应禁止抛出异常，防止程序终止。综上，结合 noexcept、type traits 与 RAII 可提升模板代码的健壮性与通用性。
在C++中，异常处理与模板编程是两个强大但复杂的特性。当它们结合使用时，尤其是涉及模板类中的成员函数抛出或传播异常时，需要特别注意类型推导、异常安全性和编译期行为。掌握它们的交互方式，有助于写出更健壮、通用的代码。
异常在模板类中的传播机制
模板类本身不改变异常传播的基本规则：如果一个函数抛出异常而未在当前作用域捕获，该异常会沿着调用栈向上传播。但在模板中，由于类型在编译期才确定，异常的传播路径可能因实例化类型不同而产生差异。
例如，一个模板类的成员函数调用某个依赖于模板参数的对象方法，该方法可能抛出异常：
template <typename T>
class SafeContainer {
public:
void push(const T& value) {
try {
data.push_back(value); // T的构造或赋值可能抛出异常
} catch (...) {
throw; // 重新抛出，保持异常传播
}
}
private:
std::vector<T> data;
};
这里，push 函数本身不直接抛出异常，但 data.push_back(value) 可能因 T 的构造函数失败而抛出。异常会被 catch 捕获后重新 throw，确保调用者仍能处理。
立即学习“C++免费学习笔记（深入）”；
模板函数中异常规范的设计建议
现代C++推荐使用 noexcept 来明确标记不抛出异常的函数，这对模板尤为重要，因为异常规范会影响类型的行为（如 std::vector 在移动时是否使用 noexcept 移动构造）。
技巧如下：
- 对仅执行基本操作（如赋值、复制 POD 类型）的模板函数，标记为 noexcept(noexcept(...)) 形式，实现条件 noexcept
- 避免在模板中使用过时的异常规范（如 throw(TException)）
- 利用 std::is_nothrow_copy_constructible 等 type traits 在编译期判断异常安全性
template <typename T>
void swap(T& a, T& b) noexcept(std::is_nothrow_move_constructible<T>::value &&
std::is_nothrow_move_assignable<T>::value) {
T tmp = std::move(a);
a = std::move(b);
b = std::move(tmp);
}
异常安全的模板类设计策略
模板类需要为所有可能的 T 提供基本异常安全保证（如 RAII、不泄漏资源）。常见技巧包括：
- 在构造函数中抛出异常前，确保已分配资源能被自动释放（如使用智能指针）
- 提供强异常安全保证的操作时，采用“拷贝再交换”模式
- 避免在析构函数中抛出异常，即使在模板中也应如此
示例：使用 copy-and-swap 实现赋值操作符
template <typename T>
class ValueHolder {
T value;
public:
ValueHolder& operator=(ValueHolder other) noexcept {
swap(*this, other);
return *this;
}
friend void swap(ValueHolder& a, ValueHolder& b) noexcept {
using std::swap;
swap(a.value, b.value);
}
};
这个赋值操作符在复制构造 other 时可能抛出异常，但此时原对象尚未修改，保证了强异常安全。
基本上就这些关键点。异常传播在模板中不会自动消失，反而因泛型而更需谨慎。结合 noexcept、type traits 和 RAII 模式，能有效提升模板代码的鲁棒性。不复杂但容易忽略。
