本书之前的章节中,我们还没对异常进行过捕获。不过对于流对象不会抛出异常,所以很容易使用。当我们想要解析10个数,不过解析过程在中途失败了,那么流对象将会将自身设置为失败状态,并且不会继续对数字进行解析。这样,我们就不会让程序处于危险当中。我们可以将解析过程转换为一个条件变量,比如if (cin >> foo >> bar >> ...)
。如果这个判断失败了,那我们将对输入进行处理。所以,这里并不会出现try-catch
代码块。
实际上,之前的C++输入输出流是会抛出异常的。异常这个特性是不是一开始就有的,所以这也可能是流对象库并不是第一个支持异常特性的原因。
为了对流使用异常,我们必须对每个流对象单独进行配置,让其在失败的时候抛出一个异常。不幸的是,我们可以对对象的异常进行捕获,但是这步并没有标准化。这就导致我们无法获得有效的错误信息,我们将在后续的实例中看到。如果我们很想对流对象使用异常,那么可以使用C库中有关文件系统错误状态,来获取更多的信息。
本节中,我们将会通过不同的方式,让程序运行失败,然后来处理这些异常,并且了解如何获取更多的有效信息。
我们将会让程序打开一个文件(这个过程可能会失败),并且将会从文件中读取一个整型数字(也可能会失败)。我们可以通过激活异常的方式来发现错误,然后再来看如何对这些错误进行处理:
-
包含必要的头文件,并声明所使用的命名空间:
#include <iostream> #include <fstream> #include <system_error> #include <cstring> using namespace std;
-
当我们要将流对象和异常一起使用时,首先需要启动异常。为了获取一个文件流对象,在指定文件并不存在时,抛出一个异常;或是在解析错误时,我们需要将对应的失败原因设置到异常掩码的对应位上。当执行失败的时候,将触发一个异常。并通过激活的
failbit
和badbit
,我们能让文件系统的错误抛出异常,并对这个错误进行解析:int main() { ifstream f; f.exceptions(f.failbit | f.badbit);
-
现在可以使用
try
块进行对文件的访问。文件打开成功,那我们将继续读取文件中的整型数字。并且,只有在读取数字成功的情况下,我们才会对数字进行打印:try { f.open("non_existant.txt"); int i; f >> i; cout << "integer has value: " << i << '\n'; }
-
对于可能发生的两种错误,一个
std::ios_base::failure
实例将会抛出。这个对象有一个what()
成员函数,其会为我们解释触发了哪种异常。不幸的是,并不存在标准化的信息,所以我们不会得到太多有用的信息。不过,我们至少可以区分,触发异常的是一个文件系统问题,还是一个格式解析问题。全局变量errno
,其在C++诞生前就存在,其会设置为一个错误值,可供我们进行查看。strerror
函数会将一个错误值,翻译为我们可以读懂的字符串。当errno
是0时,就代表文件系统没有任何错误:catch (ios_base::failure& e) { cerr << "Caught error: "; if (errno) { cerr << strerror(errno) << '\n'; } else { cerr << e.what() << '\n'; } } }
-
编译并运行程序,两种错误可能都会在运行时发生。当文件不存在时,我们就不可能从文件中获取数值,所以我们会得到一个
iostream_category
错误信息:$ ./readable_error_msg Caught error: ios_base::clear: unspecified iostream_category
-
如果文件不存在,
strerror(errno)
将会返回不同的错误信息:$ ./readable_error_msg Caught error: No such file or directory
我们可以通过 s.exceptions(s.failbit | s.badbit)
使能流对象s抛出异常的能力。不过,这也就意味着有些情况无法使用异常,例如std::ifstream
的实例需要打开一个文件进行构造,所以我们不能在之后对异常进行设置。
ifstream f {"non_existant.txt"};
f.exceptions(...); // too late for an exception
这就十分遗憾了,因为异常处理与原始C风格的方式进行对比,无需被if
困扰,其每一步都是在处理异常。
当我们使用各种方法让流处于失败的状态,就会发现抛出的这些异常并没有什么区别。这样只需要了解何时捕获错误,而非捕获了什么错误(对于流是这样,而对于STL中的其他类型就不是了),这也就是为什么我们要对errno
的值进行检查的原因。这个全局变量在C++和异常诞生之前,就已经存在了。
如果有任何与系统相关的函数发生了错误,其会将errno
设置为除0之外的其他值(0代表没有错误),然后调用者可以通过对errno
值的查询,来了解到底出现了什么问题。这个问题我们在多线程程序会经常遇到,并且所有线程都会对一个全局变量进行修改,那么当出现错误了,是哪个线程造成的呢?幸运的是,这个设计已经在C++11中进行了修改,每个线程都只能看到属于自己的erron
变量。
对于原始的错误处理方式,我们就不进行详细的描述了,不过其能为我们提供额外有用的信息,比如流对象触发了基于系统的异常。异常会告诉我们发生了什么,而erron
则会告诉我们会发生哪种级别的错误。