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

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

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