函数try块是唯一能捕获构造函数初始化列表中异常的机制，因其覆盖基类构造、成员初始化及函数体；catch中异常会被强制重抛，仅适用于日志、类型转换或终止前审计。
构造函数初始化列表中抛出的异常必须用函数try块捕获
普通 try 块无法捕获初始化列表里的异常——因为初始化列表在构造函数体执行前就运行了，而常规 try 块只包裹函数体。只有函数try块（function-try-block）能覆盖整个构造过程，包括基类构造、成员初始化和函数体。
- 初始化列表中调用可能抛异常的基类构造函数时，如
B()抛出std::runtime_error，不加函数try块会导致异常直接逃逸，无法局部处理 - 函数try块的
catch中无法“真正”吞掉异常：C++标准强制要求，一旦进入函数try块的catch，无论是否显式throw，该异常都会被自动重新抛出（除非程序已调用std::terminate） - 常见误用是想在
catch里记录日志后“静默恢复”，这不可行；它只适合做清理、转换异常类型（如throw std::logic_error("...")）或终止程序前审计
函数try块语法和典型结构长什么样
函数try块把整个函数体（含初始化列表）包进 try，catch 必须紧跟其后，不能有中间语句。注意冒号位置和花括号嵌套层级：
struct A : B {
A() try : B(), m_x(42), m_y(init_with_throw()) {
// 正常构造体
} catch (const std::exception& e) {
std::cerr << "Failed to construct A: " << e.what() << '\n';
throw; // 这里 throw; 是隐式重抛，不可省略
}
private:
int m_x;
std::string m_y;
};
-
try关键字紧贴函数头之后，冒号（初始化列表起始）必须在try后面 -
catch块不能访问构造函数的参数（它们在初始化列表阶段已消耗），也不能访问this指向的完整对象（因为对象尚未构造完成） - 若基类
B构造失败，A的成员变量（如m_x）根本不会被初始化，其析构函数也不会被调用
为什么不用普通 try-catch 包裹构造函数体
写成这样是无效的：
A() : B(), m_x(42) {
try {
m_y = init_with_throw(); // 错！这里才开始执行，但初始化列表里的异常早已发生
} catch (...) { /* 永远捕获不到 B() 或 m_x 初始化的异常 */ }
}
- 初始化列表中的异常（如
B()构造失败）发生在函数体之前，此时普通try块还没开始，异常直接向上层传播 - 函数体内的
try只能捕获函数体内部语句抛出的异常，对初始化阶段完全无感 - 试图把所有逻辑塞进函数体再初始化成员，会失去 RAII 优势，且无法保证基类先于派生类构造的顺序语义
函数try块在析构函数里基本没用
C++ 明确禁止在析构函数中让异常逃逸（否则调用 std::terminate）。函数try块虽可用于析构函数，但实际意义极小：
立即学习“C++免费学习笔记（深入）”；
- 即使你写了析构函数的函数try块，
catch里也几乎不能做任何有用的事——既不能阻止异常传播（因为重抛仍会触发terminate），又不能安全地throw新异常 - 更现实的做法是：在析构函数内用
noexcept显式声明，或确保所有操作都不抛异常（比如用std::uncaught_exceptions()判断当前是否已在栈展开中） - 函数try块在析构函数中属于技术上可行但工程上应避免的冷路径，多数现代代码库直接禁用
函数try块是个窄口径工具：它只解决“初始化列表异常无法捕获”这一个痛点，且捕获后无法真正压制异常。最容易被忽略的是它的重抛语义——你以为 catch 住了，其实只是加了一层日志或类型转换的跳板。
