第三方库异常未被catch住，主因是类型不匹配：boost、openssl等库抛出非std::exception派生类（如boost::system::system_error），且c++不支持跨类型隐式转换，必须显式按文档逐个捕获，或分层使用具体类型→std::exception→catch(...)兜底。
第三方库异常没被 catch 住，是因为类型不匹配
多数 C++ 第三方库（如 Boost、OpenSSL、SQLite3 C++ 封装）抛出的异常类型不是 std::exception 派生类，或者用了自定义命名空间（如 boost::system::system_error），直接写 catch (const std::exception& e) 会漏掉。编译器不会自动转换，C++ 也不支持跨类型隐式转换异常。
必须显式列出所有可能抛出的异常类型
没有“万能 catch”，只能按库文档或头文件声明，逐个捕获。常见做法是分层 catch：先捕具体类型，再兜底 std::exception，最后用 ... 捕未知类型（慎用，会掩盖问题）。
-
catch (const boost::system::system_error& e)—— Boost.Asio 常见 -
catch (const pqxx::sql_error& e)—— libpqxx PostgreSQL 封装 -
catch (const std::runtime_error& e)—— 部分库内部转为标准异常，但不能依赖 -
catch (...)仅用于日志记录 + 重新抛出，避免吞异常
封装转换函数时，别在 catch 块里 new 对象
想统一转成自己项目的 MyAppError 类型？别在 catch 块里调用可能抛异常的构造函数或分配内存（比如含 std::string 成员的拷贝），否则二次崩溃。安全做法是用 noexcept 构造函数，或只存错误码和 C 字符串。
class MyAppError {
public:
explicit MyAppError(int code, const char* msg) noexcept
: m_code(code), m_msg(msg) {}
private:
int m_code;
const char* m_msg; // 不持有堆内存
};
转换示例：
try {
some_third_party_call();
} catch (const boost::system::system_error& e) {
throw MyAppError(e.code().value(), e.what());
} catch (const std::exception& e) {
throw MyAppError(-1, e.what());
}
链接时符号可见性影响异常类型识别
如果第三方库是动态链接且编译时用了 -fvisibility=hidden（常见于 Linux shared library），它的异常类符号可能不可见，导致 catch 失败——看起来像没捕到，其实是 RTTI 不匹配。解决方法：
- 确认库是否导出了异常类符号（查其头文件是否有
__attribute__((visibility("default")))或等效宏） - 自己的代码编译时加
-fvisibility=default（不推荐全局改），或仅对包含该库头文件的 TU 加#pragma GCC visibility push(default) - 优先使用静态链接，规避符号隐藏问题
最麻烦的是某些 C 封装库（如 OpenSSL）根本不用 C++ 异常，而是靠返回码 + ERR_get_error()，这种得彻底放弃 try/catch，改用错误码检查流程。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
