异常


1. Standard Exception Classes
1)Exceptions for language support
bad_alloc
bad_cast
bad_typeid
bad_exception

2)Exceptions for the C++ standard library(logic_error)
invalid_argument
length_error
out_of_range
domain_error

3)Exceptions for errors outside the scope of a program(runtime_error)
range_error
overflow_error
underflow_error

4)ios_base::failure


2. Abrahams Guarantee

基本保证(basic guarantee): 失败的操作可能会改变程序的状态, 但是不会发生任何泄露, 受失败的操作影响的对象/模块仍然可用,可析构,并处于一致的状态下(不过该状态并不一定是可预测的)。
强保证(strong guarantee): 事物提交/回滚语义,从被操作的对象的角度来说, 操作失败也不会导致程序状态改变, 不会产生任何副作用。
无失败保证指根本不允许失败的发生。
重点:
1)实现强保证, 经常需要放弃一部分性能为代价。
2)如果一个函数含有多个副作用,那么其总是无法成为强异常安全的, 此时唯一的办法就是将函数分解, 以使每个分解出来的函数之副作用能被自动完成。
3)并不是所有函数都需要具有强异常安全性。
3. 对象的生命期
开始:当他的构造函数成功执行完毕并正常返回时。 (控制流抵达构造函数体的末尾时)
结束:当析构函数开始执行时。(控制流抵达析构函数的开始之处时)


4. 构造函数/析构函数抛出异常

构造函数抛出异常:
构造失败,对象从没存在过, 他的生命期还没开始, 析构函数永远不会被调用。
C++仅仅能删除被完全构造的对象(fully contructed objects), 只有一个对象的构造函数完全运行完毕,这个对象才能被完全地构造。C++拒绝为没有完成构造操作的对象调用析构函数。
析构函数抛出异常:
我们知道禁止异常传递到析构函数外有两个原因,第一能够在异常转递的堆栈辗转开解(stack-unwinding)的过程中,防止terminate被调用。第二它能帮助确保析构函数总能完成我们希望它做的所有事情。


5. 具有强烈异常安全性的拷贝赋值的规范形式

首先,提供一个不抛出异常的swap()函数,用以交换两个对象的内容.
接着,运用创建一个临时对象然后交换的手法来实现operator=


6. 尽量通过析构函数来进行一场环境下来的自动清理工作, 而不是通过try/catch


7. 异常处理原则

为应用程序或子系统确立一个整体的错误报告处理策略, 并且始终遵循它,并为错误报告,错误传播以及错误处理制定策略
在那些侦测到错误,自身又无法处理的地方抛出异常
在那些具有足够知识和上下文信息去处理/转换错误或强制实施边界条件的地方编写try/catch


8. 异常安全

函数应当总是支持他所能支持的最强的异常安全保证, 前提是不能给那些并不需要该保证的调用者带来额外的开销

永远不要允许析构函数, 释放操作, 以及swap()函数抛出异常, 否则没法安全且可靠地进行资源清理


9. 异常规格

永远不要为函数加上异常规格,除非你想声明的是空异常规格列表, 但是这也没有必要


10. 异常workflow
C++规范要求被做为异常抛出的对象必须被复制。即使被抛出的对象不会被释放,也会进行拷贝操作。这表示即使通过引用来捕获异常,也不能在catch块中修改异常对象;仅仅能修改他的拷贝。
通过引用捕获异常 
一般来说,你应该用throw来重新抛出当前的异常,因为这样不会改变被传递出去的异常类型,而且更有效率,因为不用生成一个新拷贝。 
一般来说,catch子句匹配异常类型时不会进行隐式类型转换。 
catch子句进行异常类型匹配的顺序是它们在源代码中出现的顺序。

你可能感兴趣的:(异常)