这节和异常有关，这一块是我不太熟悉的，只能先把自己理解的记录下来。

　1 class Widget
　2 {
　3 public:
　4　　
　5　　 ~Widget() {} //假设这里会吐出一个异常
　6 };
　7
　8 void doSomething()
　9 {
10　　 std::vector<Widget> v;
11　　
12 }//v在这里自动销毁

　　上面的代码中，假设v含有10个Widget，如果在前面几个的析构函数中弹出异常，则程序会过早结束或者出现不明确行为。

　　确实不鼓励在析构函数中抛出异常，可是如果程序在析构函数中必须执行一个动作，而该动作可能会在失败时抛出异常，该怎么办呢？比如下例：

1 class DBConnection
2 {
3 public:
4　　 static DBConnection create();
5　　 void close();//关闭连接，失败则抛出异常
6 };

　　为了确保用户不忘记调用close（）关闭连接，我们可以创建一个管理DBConnection资源的类：　

　1 class DBConn
　2 {
　3 public:
　4　　 ~DBConn()
　5　　 {
　6　　　　 db.close();
　7　　 }
　8 private:
　9　　 DBConnection db;
10 };

　　这样在使用时，如果close没有异常，则会很完美，不然DBConn就会使得它离开close函数，这会出现上述问题。

　　我们可以在DBConn的析构函数中，自己提前处理这个异常，但是这么做对于“导致close抛出异常”的情况无法做出反应。

　　一个比较好的策略是重新定义DBConn接口，给用户一个机会自己处理这种异常，比如，给用户定义一个函数close：

　1 class DBConn
　2 {
　3 public:
　4　　 void close()//让用户有机会自己捕捉异常
　5　　 {
　6　　　　 db.close();
　7　　　　 closed = true;
　8　　 }
　9
10　　 ~DBConn()
11　　 {
12　　　　 if(!closed)
13　　　　 {
14　　　　　　 try{
15　　　　　　　　 db.close();
16　　　　　　 }
17　　　　　　 catch(){
18　　　　　　　　 //记录下对close的调用失败
19　　　　　　 }
20　　 }
21 private:
22　　 DBConnection db;
23　　 bool closed;
24 };

　　这样一来，就有了双保险，用户可以自己处理异常，如果他们不处理，则析构函数会自动吞下异常。

　　总结：

　　1.在析构函数中尽可能不要吐出异常，如果真要吐出就在析构函数中捕获所以的异常，并提前结束程序或吞下它们；

　　2.如果用户需要自己处理异常，则在类中应该提供一个普通函数处理。

　　系列文章：

　　《Effective C++》读书笔记01：视c++为一个语言联邦

　　《Effective C++》读书笔记02：用const，enum，inline减少#define出场机会

　　《Effective C++》读书笔记03：多才多艺的const

　　《Effective C++》读书笔记04：确保对象在使用之前被初始化

　　《Effective C++》读书笔记05：c++默默为您编写的函数

　　《Effective C++》读书笔记06：如果不要编译器自动生成的函数，就明确拒绝

　　《Effective C++》读书笔记07：为多态基类声明virtual析构函数

　　《Effective C++》读书笔记08：别让异常逃离析构函数

　　《Effective C++》读书笔记09：绝不在构造和析构过程中调用virtual函数

　　《Effective C++》读书笔记10：令operator=返回一个引用指向*this