首页 > 代码库 > 【C++】异常简述(三):补充之如何看待C++异常

【C++】异常简述(三):补充之如何看待C++异常

  C++异常的使用,我相信在上文总结的已经比较完整了,本文主要对C++异常这块进行额外的补充.

  即使C++将异常纳入标准已经很多年了,但是直到现在都能看到很多坚持不显式使用异常.(包括本人在内,在写的代码中很少使用异常).

  在评论异常之前,首先引入google C++ 编码规范,我们先来看看谷歌怎么看待C++异常.

6. 异常(Exceptions)

不要使用C++异常。

优点:

1)异常允许上层应用决定如何处理在底层嵌套函数中发生的“不可能发生”的失败,不像出错代码的记录那么模糊费解;
2)应用于其他很多现代语言中,引入异常使得C++与Python、Java及其他与C++相近的语言更加兼容;
3)许多C++第三方库使用异常,关闭异常将导致难以与之结合;
4)异常是解决构造函数失败的唯一方案,虽然可以通过工厂函数(factory function)或Init()方法模拟异常,但他们分别需要堆分配或新的“非法”状态;
5)在测试框架(testing framework)中,异常确实很好用。

缺点:

1)在现有函数中添加throw语句时,必须检查所有调用处,即使它们至少具有基本的异常安全保护,或者程序正常结束,永远不可能捕获该异常。
例如:如果f()依次调用了g()和h(),h抛出被f捕获的异常,g就要当心了,避免没有完全清理;
2) 通俗一点说,异常会导致程序控制流(control flow)通过查看代码无法确定:函数有可能在不确定的地方返回,从而导致代码管理和调试困难,当然,你可以通过规定何时何地如何使用异常来最小化的降低开销,却给开发人员带来掌握这些规定的负担;
3)异常安全需要RAII和不同编码实践。轻松、正确编写异常安全代码需要大量支撑。允许使用异常;
4)加入异常使二进制执行代码体积变大,增加了编译时长(或许影响不大),还可能增加地址空间压力;
5)异常的实用性可能会刺激开发人员在不恰当的时候抛出异常,或者在不安全的地方从异常中恢复,
例如,非法用户输入可能导致抛出异常。如果允许使用异常会使得这样一篇编程风格指南长出很多(译者注,这个理由有点牵强:-()!

结论:

从表面上看,使用异常利大于弊,尤其是在新项目中,然而,对于现有代码,引入异常会牵连到所有依赖代码。
如果允许异常在新项目中使用,在跟以前没有使用异常的代码整合时也是一个麻烦。
因为Google现有的大多数C++代码都没有异常处理,引入带有异常处理的新代码相当困难。
鉴于Google现有代码不接受异常,在现有代码中使用异常比在新项目中使用的代价多少要大一点,迁移过程会比较慢,也容易出错。我们也不相信异常的有效替代方案,如错误代码、断言等,都是严重负担。
我们并不是基于哲学或道德层面反对使用异常,而是在实践的基础上。因为我们希望使用Google上的开源项目,但项目中使用异常会为此带来不便,因为我们也建议不要在Google上的开源项目中使用异常,如果我们需要把这些项目推倒重来显然不太现实。
对于Windows代码来说,这一点有个例外(等到最后一篇吧:D)。
注:对于异常处理,显然不是短短几句话能够说清楚的,以构造函数为例,很多C++书籍上都提到当构造失败时只有异常可以处理,Google禁止使用异常这一点,仅仅是为了自身的方便,说大了,无非是基于软件管理成本上,实际使用中还是自己决定。

  在这里还有更多对C++异常的讨论:https://www.zhihu.com/question/22889420

【C++】异常简述(三):补充之如何看待C++异常