C++异常处理机制----读书笔记（下篇）

最新推荐文章于 2021-04-10 20:41:39 发布

Icehand哥

最新推荐文章于 2021-04-10 20:41:39 发布

阅读量685

点赞数

分类专栏： C++ 文章标签：异常处理 exception c++

本文链接：https://blog.csdn.net/blood_flowing/article/details/23874047

版权

C++ 专栏收录该内容

18 篇文章 1 订阅

订阅专栏

前言

此篇主要的描述的是一些非常规的异常处理办法。

资源管理

当一个函数申请了某种资源----比如说，打开一个文件，在自由空间分配了一些存储，设置过某种访问控制锁等。一个至关重要的问题是应该怎样释放这种资源，也就是要求这些申请资源的函数在返回其调用者之前完成这种释放。

例如：

void use_file(const char *fn){
      FILE *f = fopen(fn,"r");
      //使用f
      fclose(f);
}

这看起来是正确的，然而若在文件打开之后，文件关闭之前，出现了一些毛病。一个异常就会导致use_file()退出，却没有去调用fclose()。甚至不支持异常的语言里也会发生此样的问题。

第一个我们能想的使use_file()能够容错的办法可能具有下面的样子：

void use_file(const char *fn){
      FILE *f = fopen(fn,"r");
      try{
            //使用f
      }
      catch(...){
            fclose(f);
            throw;
      }
      fclose(f);
}

然而这种解决办法并不优美，而且可能代价高昂。此时，不知道你是否会想到一个东西----智能指针。它是为了确保new出的资源占用能够被delete掉的一种技术。

因此，我们可以仿造智能指针，定义一个File_ptr;

class File_ptr{
      FILE *P;
public:
      File_ptr(const char *n,const char *a){p = fopen(n,a);}
      File_ptr(FILE *pp){p=pp;}
      ~File_ptr(){if(p) fclose(p);}
      operator FILE*(){return p;}
};

在给了一个FILE*或者fopen()所需要的参数我们就可以创建一个File_ptr类，在这两者情况下，这个File_ptr在其作用域结束时被销毁，它的析构函数就会关闭对应的文件。

现在我们的函数可以写为：

void use_file(const char *fn){
      File_ptr(fn,"r");
      //使用f
}

上述，析构函数总会被调用，无论该函数是正常结束还是因为抛出了某个异常而退出。

构造函数里的异常

我们先来看一个例子：

class Y{
      int *p;
      void init();
public:
      Y(int s){ p = new int[s];init();}
       ~Y(){delete []p;}
       //........
};

这样的构造函数看似正常，却暗藏风险。如果init()抛出异常，那么申请到的存储就不会被释放，因为有关对象的构造并没有完成。对它不会调用析构函数，那么对它的一种安全变形就是：

class Z{
      vector<int> p;
      void init();
public:
       Z(int s):p(s){init();}
       //........
};

通过p，使用的资源由vector管理，如果init()抛出异常，在p的析构函数调用时，已经申请到的存储就会被释放。

我们可以总结一下，当面对那些要求多种资源的构造函数的时候，上述那种“资源申请即处理化”技术无疑是最安全最优美的方法。

当然，我们的无资源申请的构造函数也会出现常规异常问题如下：

class X{
public:
	class Size{};
	enum{MAX = 32000};
	X(int sz){
		if(sz<0||sz>MAX)throw Size();
        //.......
	}
};

此时，创建X的代码可以捕捉到X::Size异常。

X* f(int i){
	try{
		X *p = new X(i);
		//........
		return p;
	}
	catch(X::Size){
		//处理size错误
	}
}

与其他构造函数一样，复制构造函数也可能通过抛出异常方式发出一个失败的信号。而此时并没有创建对象。

关于浅拷贝与深拷贝的异常处理，不在这里做详尽的讨论。

析构函数的异常

从异常处理的角度看，析构函数可能在以下两种情况下被调用：

(1) 正常调用。某个作用域正常退出的结果，作为一个delete操作的结果等。

(2)在异常处理中被调用。在堆栈回退的过程中，异常处理机制回退一个作用域，其中包含有析构函数的对象。

对于后一种情况，决不能让析构函数抛出异常。
C++并不禁止析构函数突出异常，但它不鼓励你这样做。这是有理由的。

考虑以下代码：

class Widget{
public:
	//.......
	~Widget(){.....}  //假设这里吐出一个异常
};
void dosomething(){
	std::vector<Widget> v;
	...               // v在这里被自动销毁
}

当vector v 被自动销毁时，它有责任销毁其内含的所有 Widget。假设v内含有10个Widget，而在析构第1个元素期间，有个异常被抛出。其他9个Widget还是应该被销毁（否则它们保存的任何资源都会发生内存泄露），因此v应该调用它的各个析构函数。但假设在那些调用期间，第二个Widget析构函数又抛出异常。现在有两个同时作用的异常，这对于C++来说已经太多了，此时程序如不是理解结束执行，就是导致不明确行为。

是的C++不喜欢析构函数吐出异常。

如果你的析构函数必须执行一个动作，而该动作可能会在失败的时候抛出异常，该怎么办呢？

我们来看下面一个例子：

class DBConnection{
public:
	....
	static DBConnection create();//这个函数返回DBConnection对象
	void close();             //关闭联机，失败的时候抛出异常
};

为确保客户不忘记在DBConnection对象上调用close()，一个合理的想法是创建一个用来管理DBConnection资源的class，并在其析构函数中调用close。代码如下：

class DBConn{
public:
	...
	~DBConn(){
		db_.close();
	}
private:
	DBConnection db_;
};

只要调用成功，一切美好。但如果调用异常，DBConn析构函数就会传播该异常，也就是允许它离开这个析构函数。

两个办法可以避免上述问题。

1.通过调用abort完成。

DBConn::~DBConn(){
	try{db_.close();}
	catch(...){
		//记录日志
		abort();
	}
}

这样利用abort抢先制“不明确行为“于死地的做法，有点极端。

2.吞下因close而发生的异常。

具体做法就是在上述代码中去掉abort()函数。

一般而言，将异常吞掉不是个好主意。因为它压制了”某些动作失败“的重要信息。

不是错误的异常

如果某个异常是有预期的，而且被捕捉到，根本不会对程序产生不良影响。那么还把它视为一种错误码？换一种看法，我们认为异常处理机制不过是另一种控制结构罢了，与局部控制结构如if和for想比，异常处理是一种结构话更差的机制而已。通常在实际抛出异常的效率也更低。因此，应该只把异常机制用在那些使用常规控制结构很不优美甚至不可行的地方。

在任何时候，只要有可能，我们还是应该坚持“异常处理就是错误处理”的观点。如果我们这样做了，在代码中就能清晰地划分为两类情况：正常代码和错误处理代码。