google abseil建议在c++中尽量避免使用异常，仅用于真正异常情况。1. 不将异常用于流程控制，仅用于不可恢复错误；2. catch块应先具体后通用，防止屏蔽子类；3. 若禁用异常，需规避可能抛异常的stl函数、第三方库，并改用工厂函数处理构造错误。
在C++开发中，异常处理是一个既强大又容易被误用的机制。Google的Abseil库作为其内部C++代码风格和最佳实践的一个开源代表，对异常处理的态度非常明确：尽量避免使用异常。但这并不意味着完全否定它的价值，而是强调在特定场景下如何更安全、高效地使用。
异常不是流程控制工具
很多人习惯性地把异常当作一种“错误跳转”手段来使用，比如：
- 在函数调用失败时抛出异常而不是返回错误码
- 用异常代替常规的条件判断逻辑
这种做法不仅让代码变得难以追踪，还可能带来性能上的问题。异常处理机制本身是有开销的，在没有发生异常时虽然影响不大，但一旦频繁抛出和捕获异常，性能就会显著下降。
立即学习“C++免费学习笔记（深入）”；
所以，Abseil建议：
- 不要将异常用于正常流程控制
- 仅用于真正“异常”的情况，例如资源加载失败、不可恢复的运行时错误等
catch块顺序很重要：从具体到通用
如果你确实需要使用try/catch结构，一定要注意catch块的顺序。常见的错误是把通用的捕获类型（如std::exception）放在最前面，这样会屏蔽掉具体的异常类型。
在 Linux 上通过 Chrome 挂载/VNC 自动发布小红书长笔记。Agent 撰写标题和正文后执行 xhs_publish.sh --publish --submit，触发小红书发布。
举个例子：
try {
// 可能抛出 std::out_of_range 或 std::exception
} catch (const std::exception& e) {
// 这里会先匹配所有 std::exception 子类，包括 std::out_of_range
} catch (const std::out_of_range& e) {
// 永远执行不到
}正确的做法是：
- 先捕获最具体的异常类型
- 最后再兜底一个通用的
std::exception
像这样：
try {
// ...
} catch (const std::out_of_range& e) {
// 处理 out_of_range
} catch (const std::bad_alloc& e) {
// 处理 bad_alloc
} catch (const std::exception& e) {
// 处理其他标准异常
}如果禁用异常，要做好兼容准备
Abseil项目默认禁用异常（通过编译器选项 -fno-exceptions），这是Google C++编码规范的一部分。如果你也选择这样做，需要注意几点：
-
不能使用任何会抛出异常的 STL 组件，比如
vector::at()，它在越界时会抛出std::out_of_range - 避免依赖那些强制使用异常的第三方库，或者为它们做封装
- 构造函数无法通过返回值报告错误，可以考虑用工厂函数或初始化方法替代，例如：
class MyClass {
public:
static std::unique_ptr<MyClass> Create() {
auto obj = std::make_unique<MyClass>();
if (!obj->Init()) return nullptr;
return obj;
}
private:
bool Init() {
// 初始化逻辑，失败返回 false
}
};这种方式虽然略显繁琐，但在禁用异常的前提下是一种可行方案。
总结一下
Google Abseil对C++异常处理的态度很务实：不鼓励使用，但在必要时也要合理支持。如果你在项目中决定启用异常，记得遵循几个关键点：
- 不滥用异常，只用于真正的异常情况
-
catch顺序要从具体到通用 - 如果禁用异常，确保整个代码库和依赖项都做好适配
基本上就这些，说起来不复杂，但实际应用中很容易忽略细节。
