catch不触发的主因是类型不匹配：throw "hello"生成const char，而catch(std::string)无法捕获；应改用catch(const char)或throw std::string。
为什么 throw 一个 int 或 std::string 后，catch 有时不触发？
常见原因是异常类型不匹配：C++ 的 catch 是严格按类型（含 cv 限定符和引用性）匹配的。比如 throw "hello" 抛出的是 const char[6]，退化为 const char*，但写 catch (std::string e) 不会捕获它——std::string 和 const char* 是完全不同的类型，且不会自动构造。
- 抛出字面量字符串时，应
catch (const char* e)或改用throw std::string("hello") - 抛出对象时，优先用引用捕获：
catch (const std::exception& e)，避免切片和不必要的拷贝 - 若在
catch块中重新抛出，用throw;（不带表达式），而非throw e;，否则会复制异常对象并可能丢失原始类型信息
std::exception 派生类怎么选？std::runtime_error 和 std::logic_error 有什么实际区别？
区别不在技术实现，而在语义：C++ 标准规定，std::logic_error 子类（如 std::invalid_argument、std::out_of_range）表示「程序逻辑错误」，通常是可静态检查或应在开发/测试阶段发现的问题；std::runtime_error 子类（如 std::system_error、std::overflow_error）表示「运行期不可预测的失败」，比如文件不存在、网络超时、内存耗尽。
- 用户输入校验失败 →
throw std::invalid_argument("size must be > 0"); - 调用
fopen()返回nullptr→throw std::system_error(errno, std::generic_category()); - 不要滥用
std::runtime_error包裹所有错误，会模糊问题性质，影响上层决策（例如是否重试）
函数声明 noexcept 和 throw() 到底怎么影响异常传播？
throw() 是 C++98 的动态异常规范，已弃用；noexcept 是现代替代，语义更明确：若函数声明为 noexcept 却抛出异常，程序直接调用 std::terminate()，不会尝试栈展开。
void dangerous_op() noexcept {
// 若此处 throw，程序立即终止，不会执行任何局部对象析构
throw std::runtime_error("oops");
}
<p>void safe_op() noexcept(true) { /<em> 同上 </em>/ }
void may_throw() noexcept(false) { /<em> 允许抛出，等价于不写 noexcept </em>/ }- 移动构造函数、交换函数（
swap）等关键操作应尽量标记noexcept，否则容器（如std::vector）可能降级为复制而非移动 - 不要给可能调用未知第三方代码的函数加
noexcept，除非你完全掌控所有可能路径 -
noexcept(expr)是运算符，用于条件判断：noexcept(my_func())返回bool编译期常量
为什么在析构函数里 throw 很危险？
析构函数默认是 noexcept(true)。如果在析构中抛出异常，而此时栈上已有未处理的异常（比如另一个对象析构时已抛出），C++ 会立即调用 std::terminate()——没有机会 catch，也没有日志输出。
立即学习“C++免费学习笔记（深入）”；
- 绝对不要在析构函数中
throw，这是硬性约束 - 若必须报告错误（如关闭文件失败），改用日志、设置标志位、或调用
std::abort()（比静默失败更可控） - RAII 类型（如智能指针、锁）的析构函数都严格遵守此规则，这也是它们安全的根本前提
异常处理不是兜底机制，而是显式控制流。最易被忽略的点是：异常对象的生命期只在 catch 块内有效，且跨栈帧传递时只做一次拷贝（或移动）；一旦 catch 块结束，原异常对象就销毁了。
