C++中的异常处理概要1.doc

异常处理（一） 简介大型应用软件往往是分层构建的。在最底层你会发现库函数，API函数，和私有的底层函数。然而在最高层则是用户接口组件，比如一个电子制表软件让用户填写数据表单。下面来看一种普通的航空订票系统：它的最高端是由一些GUI组件所组成，用来在用户的屏幕上显示内容。这些高端组件与那些封装了数据库API的数据存取对象相互作用。再往底层一些，那些数据库API与数据库引擎相交互，然而数据库引擎自己又会调用系统服务来处理底层的硬件资源，比如物理内存，文件系统和安全模型。一般情况下，及其严格的运行期错误会在这些底层代码中被检测出来，但是它们不能-----或者说不应该----试图自己处理这些错误。解决这些严格的运行期错误的责任应该由高端组件来承担。为了解决一个错误，高端组件必须得到错误发生的通知。本质上，错误处理包括错误检测和通知高端组件。这些组件依次处理错误并且试图从错误中恢复。 传统的错误处理方法在早些时期，C++本身并没有处理运行期错误的能力。取而代之的是那些传统的C方法。这些方法可以被归为三类设计策略：返回一个状态码来表明成功或失败把错误码赋值给一个全局标记并且让其他的函数来检测终止整个程序上述的任何一个方法在面向对象环境下都有明显的缺点和限制。其中的一些根本就不可接受，尤其是在大型应用程序中。接下来的部分将会仔细检查一下这些方法，目的是发现他们与生俱来的限制和危险性。 返回一个错误码 在某种程度上这个方法是有用的，比如一个小型程序有着一致而且有限的错误码存在，并且严格的报告错误和检查一个函数返回值的策略被应用。然而，这种方法也有着显著的局限性；例如，错误类型和它们的列举值必须标准化。因为一个库的实现者可能选择返回值0来代表一个错误，然而另一个实现者却选择0来代表成功并且用那些非0值代表出现错误。通常，那些返回码会在一个公共头文件中以符号常量的形式存在，从而在整个软件的开发过程中或者在一个开发团队里达成一致。但是，这些码并不是标准的。不用说，在结合那些不兼容的软件库的时候，如何处理非标准的错误码将会是一件极其头疼的事。另外一个缺点是对于每一个返回码都必须查阅和解释------一个乏味并且昂贵的操作。这个策略的实现需要调用者在每一次调用的时候对返回值进行检查，如果没有这样做将会导致运行期错误。当一个错误码被检测，就会终止正常的执行流程并且把错误码传递给调用者。那些附加的包裹每一个函数调用的代码会很轻易的使程序的大小翻倍并且引起软件维护和程序可读性的降低。更糟的是，有时要想返回一个error value是不可能的。例如，构造函数没有返回值，所以就不能应用这种方法在对象构造失败的情况下报告错误。 求助于全局标记一个可选的用来报告运行期错误的途径是使用全局标记，它表明了最后的操作是否成功。不像返回码策略，这个方法是标准化的。C 的errno.h头文件中定义了一种机制用来检查和给一个全局整型标记errno赋值。这种策略固有的缺陷也是不能被忽视的。在一个多线程环境中，被一个线程赋予了一个错误码的errno有可能不经意的被另一个线程所改写，而调用者还未对errno进行检查。另外，对错误码而不是一个更为可读的信息的使用是很不利的，因为那些错误码可能会在不同的环境中不兼容。最终，这种方法需要严格的良好的编程样式，也就是不断的对errno的当前值进行检查。全局标记策略和函数返回值策略是相似的：二者都提供一种机制来报告错误，但是二者却都不能保证错误被处理。例如，一个函数没有成功打开一个文件可以通过给errno赋予一个合适的值来表明错误的发生。然而，它不能阻止另一个函数试图写入和关闭那个文件。更进一步，如果errno表明一个错误并且程序员检测到而且按照预期处理了它，那么errno还应该被显式的复位。如果一个程序员忘记了做这件事，那么将会引起其他函数误以为错误还没有被处理，从而去校正那个问题，引起不可预知的结果。 终止程序最为残酷的处理运行期错误的方法是简单的终止程序。这种解决方案去除了上面两种方法的一些缺点；例如，没有必要反复的检查每个函数返回值的状态，而且程序员也不必赋值给一个全局标记，反复的测试和清除它的值。在标准C的函数库中有两个函数用来终止一个程序：exit()和abort()。exit()被调用能够表明程序被成功终止，或者它可以在遇到运行期错误的时候被调用。在把控制权交还给运行环境之前，exit()首先会清空流和关闭打开的文件。abort()却不一样，它表示程序被意外终止，不会清空流和关闭打开的文件。关键性的程序不应该在任何运行期错误存在的情况下突然终止。如果一个生命支持系统突然停止工作仅仅是因为它的控制器检测到0做除数，那么将是一种灾难。同样，一个控制由人驾驶的航天飞机自动运行的计算机系统也不应该因为暂时的和地面控制系统失去联系就停止工作