catch throw 可在C++异常抛出瞬间中断，栈帧完整、变量可见，精准定位异常源头；需配合-g编译和-O0优化以确保有效。
用 catch throw 捕获 C++ 异常抛出点
GDB 本身不靠断点停在 throw 处，而是用 catch 命令监听运行时事件。C++ 抛出异常的瞬间（即 throw 表达式执行时），GDB 可以立即中断，此时栈帧完整、变量可见、尚未进入任何 catch 块——这是定位未捕获异常或异常构造逻辑问题的黄金位置。
实操只需一条命令：catch throw。它不要求源码有调试符号（但没 -g 编译的话，你可能看不到源行和变量名）。
- 启动 GDB 后先加载程序：
gdb ./myapp - 设置捕捉点：
catch throw（注意不是break throw，后者会报错） - 运行：
r或run，一旦有throw执行，GDB 就停住 - 验证是否生效：
info catch可列出当前所有catch点
catch throw 和 catch catch 的区别很关键
两者监听的是完全不同的时机：catch throw 停在 throw 语句执行那一刻；catch catch 则停在控制流刚进入某个 catch 子句的第一行（即异常已被处理、栈已展开一部分）。多数调试场景要的是前者——因为后者可能掩盖了异常源头，比如抛出时对象已部分析构、或原始错误上下文丢失。
-
catch throw：适合查“谁抛的”“为什么抛”“抛的是什么” -
catch catch：适合查“谁接的”“接的时候状态是否正常”“有没有二次异常” - 若只关心未被捕获的异常，
catch throw+continue几次后程序通常会因std::terminate收到SIGABRT，这时再看调用栈更准
常见失败原因：没编译调试信息或异常被优化掉
即使写了 catch throw，GDB 也可能“不触发”，最常踩的两个坑是：
- 可执行文件没加
-g：GDB 能停，但停在汇编层，list不出源码，print变量常显示<optimized out></optimized> - 启用了
-O2或更高优化：某些异常路径可能被编译器内联、消除或重排，导致throw点不可见或行为偏移；建议调试时用-O0 -g - 程序是 Release 构建且 strip 过：符号全无，
catch throw仍工作，但无法关联源码行，仅能靠bt和寄存器推测
进阶：只捕获特定类型异常
GDB 7.12+ 支持带类型的 catch，例如只在抛出 std::runtime_error 时中断：catch throw std::runtime_error。但要注意：
- 类型名必须和 ABI 中一致（如
std::runtime_error，不能简写为runtime_error） - 若异常类型是模板实例化（如
std::exception的派生类），需确保该类型符号实际存在于二进制中（有时会被 DCE 掉） - 不支持通配符或基类匹配，
catch throw std::exception不会捕获其子类，除非子类名显式写出
真正难调试的，往往是异常抛出前那一瞬的状态——变量值、内存布局、线程上下文。而 catch throw 提供的就是这个“临界快照”，别让它被优化或符号缺失悄悄绕过去。
