《More Effective C++》总结笔记(二)——异常

异常

条款9:利用destructors避免泄露资源

  • 只要坚持这个规则,把资源封装在对象内(类似智能指针shared_ptr),通常便可以在exceptions出现时避免泄露资源。
  • 简单来说就是,当有资源可能在函数抛异常时而无法释放,这时可以将资源封装到对象内(RAII),利用对象的析构函数来自动释放资源,这样即使有exceptions发生,也不会有资源泄露。

条款10:在constructors内阻止资源泄露(resource leak)

  • C++只会析构已构造完成的对象。对象只有在其constructor执行完毕才算是完成构造妥当。
  • 由于C++不自动清理那些“构造期间抛出exceptions”的对象,所以你必须设计你的constructors,使它们在那种情况下亦能自我清理。通常这只需要将所有可能的exceptions捕捉起来,执行某种清理工作,然后重新抛出exception,使它继续传播出去即可。
  • 但是,更优雅的做法实际上是将这些需要在constructor内初始化的对象视为资源,将它们交由智能指针来管理。
  • 结论是:如果你以auto_ptr(C++11后使用shared_ptr或者unique_ptr)对象来取代pointer class members,你便对你的constructors做了强化工事,免除了“exceptions出现时发生资源泄露”的危机,不再需要在destructors内亲自动手释放资源,并允许const member pointers得以和non-const member pointers有着一样优雅的处理方式。

条款11:禁止异常(exceptions)流出destructors之外

Session::Session()
{
  try {
    logDestruction(this);
  }
  catch (...) {
  }
}
  • 这里的catch语句块看起来什么都没做,但是外表容易骗人。这个语句块阻止了“logDestruction所抛出的exceptions”传出Session destructor之外。
  • 有两个好理由支持我们“全力阻止exceptions传出destructors之外”。第一,它可以避免terminate函数在exception传播过程的栈展开(stack-unwinding)机制中被调用;第二,它可以协助确保destructors完成其应该完成的所有事情。

条款12:了解“抛出一个exception”与“传递一个参数”或“调用一个虚函数”之间的差异

  • “抛出exception”与“传递参数”的相同点是:它们的传递方式有3中:by value(传值),by reference(传引用),by pointer(传指针)。然而视你所传递的是参数或exceptions,发生的事情可能完全不同。原因是当你调用一个函数,控制权最终会回到调用端(除非函数失败以至于无法返回),但是当你抛出一个exception,控制权不会再回到抛出端。
  • “抛出exception”与“传递参数”的区别一:C++特别声明,一个对象被抛出作为exception时,总是会发生复制(copy)。即使catch语句参数时by reference,或者抛出对象声明为static也一样会发生复制。且复制动作永远是以对象的静态类型为本。
  • “exception objects必定会造成复制行为”这一事实也解释了“传递参数”和“抛出exception”之间的另一个不同:后者常常比前者慢。
  • 一般而言,你必须使用一下语句:
    throw;
    才能重新抛出当前的exception,其间没有机会让你改变被传播的exception的类型。此外,它也比较有效率,因为不需要产生新的exception object。
  • “抛出exception”与“传递参数”的区别二:函数调用过程中将一个临时对象传递给一个non-const reference参数时不允许的,但对exception则属合法。
  • “抛出exception”与“传递参数”的区别三:一般而言,调用函数传递参数过程中允许的隐式转换在“exceptions与catch子句相匹配”的过程中使不会发生的。
  • “exceptions与catch子句相匹配”的过程中,仅有两种转换可以发生。第一种是“继承架构中的类转换”。第二种是从一个“有型指针”转为“无型指针”(所以一个参数为const void*的catch子句,可捕捉任何指针类型的exception)。
  • “抛出exception”与“传递参数”的区别四:catch子句总是依出现顺序做匹配尝试。与虚函数调用比较,虚函数采用”best fit“(最佳吻合)策略,而exception处理机制采用”first fit“(最先吻合)策略。因此,绝对不要将”针对base class而设计的catch子句“放在”针对derived class而设计的catch子句“之前。

条款13:以by reference方式捕捉exceptions

  • 相比于by reference方式,以by value方式捕获exception,会使被传递的对象发生两次复制,产生两个副本。其中一个构造动作用于“任何exceptions都会产生的临时对象”身上,另一个构造动作用于“将临时对象复制到catch的参数上”。
  • 千万不要抛出一个指向局部对象的指针,因为该局部对象会在exception传离其scope时被销毁,因此catch子句会获得一个指向“已被销毁的对象”的指针。
  • 如果catch by reference,你就可以避开对象删除问题(by pointer会面对的)——它会让你动辄得咎,做也不是,不做也不是;你也可以避开exception objects的切割问题(派生类对象的exception objects被捕捉并被视为基类对象的exception objects,将失去其派生成分。对象切割问题是由于静态编联导致的,使用引用和指针时不会发生);你可以保留捕捉C++标准exceptions的能力;你也约束了exception objects需被复制的次数。

条款14:明智运用exception specifications

  • exception specification示例,一个只抛出int类型exceptions的函数声明为:
void fun() throw(int);
  • 如果函数抛出一个并未列入exception specification的exception,这个错误会在运行时期被检验出来,于是特殊函数unexpected会被自动调用。unexpected的默认行为是调用terminate。
  • 想要避免这种unexpected的方法就是:
    • 不应该将templates和exception specifications混合使用。
    • 如果A函数内调用了B函数,而B函数无exception specifications,那么A函数本身也不要设定exception specifications。
    • 处理“系统”可能抛出的exceptions(如bad_alloc)。
  • C++允许你以不同类型的exceptions取代非预期的exceptions。如果非预期函数的替代者重新抛出当前的exception,该exception会被标准类型bad_exception取而代之。
void convertUnexpected()
{
  throw;
}

set_unexpected(convertUnexpected);
  • 如果你做了上述安排,并且每一个exception specifications都含有bad_exception,或者其基类,你就再也不必担心程序会于是非预期的exception时中止执行。

了解异常处理(exception handling)的成本

  • 为了让exception的相关成本最小化,只要能够不支持exceptions,编译器便不支持;请将你对try语句块和exception specifications的使用限制于非用不可的地点,并且在真正异常的情况下才抛出exceptions。

你可能感兴趣的:(C++技术,Effective,C++,读书笔记,c++,面试,指针)