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

这节和异常有关，这一块是我不太熟悉的，只能先把本身领略的记录下来。

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.假如用户需要本身处理惩罚异常，则在类中应该提供一个普通函数处理惩罚。