C与C++中的异常处理.docx
《C与C++中的异常处理.docx》由会员分享，可在线阅读，更多相关《C与C++中的异常处理.docx（31页珍藏版）》请在冰豆网上搜索。
C与C++中的异常处理
C与C++中的异常处理
（1）
1. 异常和标准C对它的支持
（前言略）
1.1 异常分类
基于Dr.GUI的建议，我把我的第一个专栏投入到“程序异常”的系列上。
我认识到，“exception”这个术语有些不明确并和上下文相关，尤其是C++标准异常（C++standardexceptions）和Microsoft的结构化异常（structuredexceptionhandling）。
不幸的的是，“异常”一词太常见了，随时出现在语言的标准和常见的编程文献中。
因为不想创造一个新名词，所以我将尽力在此系列的各部分中明确我对“异常”的用法。
l Part1概述通常意义上的异常的性质，和标准C库提供的处理它们的方法。
l Part2纵览Microsoft对这些标准C库方法的扩展：
专门的宏和结构化异常处理。
l Part3及其余将致力于标准C++异常处理体系。
（C语言使用者可能在Part2后放弃，但我鼓励你坚持到底；我所提出的许多点子同样适用于C，虽然不是很直接。
）
本质上看，程序异常是指出现了一些很少发生的或出乎意料的状态，通常显示了一个程序错误或要求一个必须提供的回应。
不能满足这个回应经常造成程序功能削弱或死亡，有时导致整个系统和它一起down掉。
不幸的是，试图使用传统的防护方法来编制健壮的代码经常只是将一个问题（意外崩溃）换成了另外一个问题（更混乱的设计和代码）。
太多的程序员认为这个交换抵不上程序意外崩溃时造成的烦恼，于是选择了生活在危险之中。
认识到这一点后，C++标准增加了一个优雅并且基本上不可见的“异常体系”到语言中；就这样，这个方法产生了。
如同我们在Part4的开始部分将要看到的，这个方法大部分情况下很成功，但在很微妙的情况下可能失败。
1.2 异常的生命阶段
在这个系列里，我将展示C和C++处理异常体系运行于异常整个生命期的每一阶段时的不同之处：
l 阶段1：
一个软件错误发生。
这个错误也许产生于一个被底层驱动或内核映射为软件错误的硬件响应事件（如被0除）。
l 阶段2：
错误的原因和性质被一个异常对象携带。
这个对象的类型可以简单的整数值到繁杂的C++类对象。
l 阶段3：
你的程序必须检测这个异常对象：
或者轮询它的存在，或者由其主动上报。
l 阶段4：
检测代码必须决定如何处理异常。
典型的方法分成三类。
a忽略异常对象，并期望别人处理它。
b在这个对象上干些什么，并还允许别人再继续处理它。
c获得异常的全部所有权。
l 阶段5：
既然异常已经处理了，程序通常恢复并继续执行。
恢复分成两种：
a恢复异常，从异常发生处继续执行。
b终止异常，从异常被处理处继续执行。
当在程序外面（由运行期库或操作系统）终止异常时，恢复经常是不可能的，程序将异常结束。
我故意忽略了硬件错误事件，因为它们完全是底层平台范围内的事。
取而代之，我假定一些软件上的可检测错误已经发生，并产生了一个处于第一阶段的软件异常对象。
1.3 C标准库异常处理体系
C标准库提供了几个方法来处理异常。
它们也全部在标准C++中有效，只是相关的头文件名字变了：
老的C标准头文件映射到了新的C++标准头文件。
（头文件名的前缀“C”是个助记符，暗示着这些全是C库头文件。
）
虽然基于向后兼容性，老的C头文件也被C++保留，但我建议你尽可能使用新的头文件。
对于绝大部分实际使用而言，最大的变化是在新的头文件中，申明的函数被包含在命名空间std内。
举个例子，C语言使用
#include
FILE*f=fopen（"blarney.txt","r"）;
在C++中被改成
#include
std:
:
FILE*f=std:
:
fopen（"blarney.txt","r"）;
或更C风格的
#include
usingnamespacestd;
FILE*f=fopen（"blarney.txt","r"）;
不幸的是，Microsoft的VisualC++没有将这些新的头文件包含在命名空间std中，虽然这是C++标准所要求的（subclauseD.5）。
除非VisualC++在这些头文件中已经正确地支持了std，我将一直在我的专栏中使用老式的C风格命名。
（象MIcrosoft这样的运行库卖主这么做是合理的，正确地实现这些C程序库的头文件极可能要求维护和测试两份完全不同的底层代码，这是不可能受欢迎的也不值得多花力气的工作。
）
1.4 无条件终止
仅次于彻底忽略一个异常，大概最容易的异常处理方法是程序自我毁灭。
有时，最懒的方法事实上是最正确的。
在你开始嘲笑以前，应该认识到，一些异常表示的状况是如此严重以致于怎么也不可能合理恢复的。
也许最好的例子就是malloc时返回NULL。
如果空闲堆管理程序不能提供可用的连续空间，你程序的健壮性将严重受损，并且恢复的可能性是渺茫的。
C库头文件提供了两个终止程序的函数：
abort（）和exit（）。
这两个函数运行于异常生命期的4和5。
它们都不会返回到其调用者中，并都导致程序结束。
这样，它们就是结束异常处理的最后一步。
虽然两个函数在概念上是相联系的，但它们的效果不同：
l abort（）：
程序异常结束。
默认情况下，调用abort（）导致运行期诊断和程序自毁。
它可能会也可能不会刷新缓冲区、关闭被打开的文件及删除临时文件，这依赖于你的编译器的具体实现。
l exit（）：
文明地结束程序。
除了关闭文件和给运行环境返回一个状态码外，exit（）还调用了你挂接的atexit（）处理程序。
一般调用abort（）处理灾难性的程序故障。
因为abort（）的默认行为是立即终止程序，你就必须负责在调用abort（）前存储重要数据。
（当我们谈论到时，你可以使得abort（）自动调用cleanup代码。
）
相反，exit（）执行了挂接在atexit（）上的自定义cleanup代码。
这些代码被按照其挂接的反序执行，你可以把它们当作虚拟析构器。
通过必要的cleanup代码，你可以安全地终止程序而没有留下尾巴。
例如：
#include
#include
staticvoidatexit_handler_1（void）
{
printf（"within''''atexit_handler_1''''\n"）;
}
staticvoidatexit_handler_2（void）
{
printf（"within''''atexit_handler_2''''\n"）;
}
intmain（void）
{
atexit（atexit_handler_1）;
atexit（atexit_handler_2）;
exit（EXIT_SUCCESS）;
printf（"thislineshouldneverappear\n"）; return0;
}
/*Whenrunyields
within''''atexit_handler_2''''
within''''atexit_handler_1''''
andreturnsasuccesscodetocallingenvironment.
*/
（注意，即使是程序从main（）正常返回而没有明确调用exit（），所挂接的atexit（）代码仍然会被调用。
）
无论abort（）还是exit（）都不会返回到它的调用者中，且都将导致程序结束。
在这个意义上来说，它们都表现为终止异常的最后一步。
1.5 有条件地终止
abort（）和exit（）让你无条件终止程序。
你还可以有条件地终止程序。
其实现体系是每个程序员所喜爱的诊断工具：
断言，定义于。
这个宏的典型实现如下所示：
#ifdefinedNDEBUG
#defineassert（condition）（（void）0）
#else
#defineassert（condition）\
_assert（（condition）,#condition,__FILE__,__LINE__）
#endif
如定义体所示，当宏NDEBUG被定义时断言是无行为的，这暗示了它只对调试版本有效。
于是，断言条件从不在非调试版本中被求值，这会造成同样的代码在调试和非调试版本间有奇妙的差异。
/*debugversion*/
#undefNDEBUG
#include
#include
intmain（void）
{
inti=0;
assert（++i!
=0）;
printf（"iis%d\n",i）;
return0;
}
/*Whenrunyields
iis1
*/
现在，通过定义NDEBUG，从debug版变到release版：
/*releaseversion*/
#defingNDEBUG
#include
#include
intmain（void）
{
inti=0;
assert（++i!
=0）;
printf（"iis%d\n",i）;
return0;
}
/*Whenrunyields
iis0
*/
要避免这个差异，必须确保断言表达式的求值不会包含有影响的副作用。
在仅供调试版使用的定义体中，断言变成呼叫_assert（）函数。
我起了这个名字，而你所用的运行库的实现可以调用任何它想调用的内部函数。
无论它叫什么，这个函数通常有以下形式：
void_assert（inttest,charconst*test_image,
charconst*file,intline）
{
if（!
test）
{
printf（"Assertionfailed:
%s,file%s,line%d\n",
test_image,file,line）;
abort（）;
}
}
所以，失败的断言在调用abort（）前显示出失败情况的诊断条件、出错的源文件名称和行号。
我在这里演示的诊断机构“printf（）”相当粗糙，你所用的运行库的实现可能产生更多的反馈信息。
断言处理了异常的阶段3到5。
它们实际上是一个带说明信息的abort（）并做了前提条件检查，如果检查失败，程序中止。
一般使用断言调试逻辑错误和绝不可能出现在正确的程序中的情况。
/*''''f''''nevercalledbyotherprograms*/
staticvoidf（int*p）
{
assert（p!
=NULL）;
/*...*/
}
对比一下逻辑错误和可以存在于正确程序中的运行期错误：
/*...getfile''''name''''fromuser...*/
FILE*file=fopen（name,mode）;
assert（file!
=NULL）;/*questionableuse*/
这样的错误表示异常情况，但不是bug。
对这些运行期异常，断言大概不是个合适的处理方法，你应该用我下面将介绍的另一个体系来代替。
1.6 非局部的跳转
与刺激的abort（）和exit（）相比,goto语句看起来是处理异常的更可行方案。
不幸的是，goto是本地的：
它只能跳到所在函数内部的标号上，而不能将控制权转移到所在程序的任意地点（当然，除非你的所有代码都在main体中）。
为了解决这个限制，C函数库提供了setjmp（）和longjmp（）函数，它们分别承担非局部标号和goto作用。
头文件申明了这些函数及同时所需的jmp_buf数据类型。
原理非常简单：
l setjmp（j）设置“jump”点，用正确的程序上下文填充jmp_buf对象j。
这个上下文包括程序存放位置、栈和框架指针，其它重要的寄存器和内存数据。
当初始化完jump的上下文，setjmp（）返回0值。
l 以后调用longjmp（j,r）的效果就是一个非局部的goto或“长跳转”到由j描述的上下文处（也就是到那原来设置j的setjmp（）处）。
当作为长跳转的目标而被调用时，setjmp（）返回r或1（如果r设为0的话）。
（记住，setjmp（）不能在这种情况时返回0。
）
通过有两类返回值，setjmp（）让你知道它正在被怎么使用。
当设置j时，setjmp（）如你期望地执行；但当作为长跳转的目标时，setjmp（）就从外面“唤醒”它的上下文。
你可以用longjmp（）来终止异常，用setjmp（）标记相应的异常处理程序。
#include
#include
jmp_bufj;
voidraise_exception（void）
{
printf（"exceptionraised\n"）;
longjmp（j,1）;/*jumptoexceptionhandler*/
printf（"thislineshouldneverappear\n"）;
}
intmain（void）
{
if（setjmp（j）==0）
{
printf（"''''setjmp''''isinitializing''''j''''\n"）;
raise_exception（）;
printf（"thislineshouldneverappear\n"）;
}
else
{
printf（"''''setjmp''''wasjustjumpedinto\n"）;
/*thiscodeistheexceptionhandler*/
}
return0;
}
/*Whenrunyields:
''''setjmp''''isinitializing''''j''''
exceptionraised
''''setjmp''''wasjustjumpedinto
*/
那个填充jmp_buf的函数不在调用longjmp（）之前返回。
否则，存储在jmp_buf中的上下文就有问题了：
jmp_bufj;
voidf（void）
{
setjmp（j）;
}
intmain（void）
{
f（）;
longjmp（j,1）;/*logicerror*/
return0;
}
所以，你必须把setjmp（）处理成只是到其所在位置的一个非局部跳转。
Longjmp（）和setjmp（）联合体运行于异常生命期的2和3阶段。
longjmp（j,r）产生异常对象r（一个整数），并且作为返回值传送到setjmp（j）处。
实际上，setjmp（）函数通报了异常r。
1.7 信号
C函数库也提供了标准的（虽然原始的）“事件”处理包。
这个包定义了一组事件和信号，以及标准的方法来触发和处理它们。
这些信号或者表示了一个异常状态或者表示了一个不协调的外部事件；基于所谈论的主题，我将只集中讨论异常信号。
为了使用这些包，需要包含标准头文件。
这个头文件申明了函数raise（）和signal（），数据类型sig_atomic_t，和以SIG开头的信号事件宏。
标准要求有六个信号宏，也许你所用的运行库实的现会再附加一些。
这些信号被固定死在中，你不能增加自定义的信号。
信号通过调用raise（）产生并被处理函数捕获。
运行时体系提供默认处理函数，但你能通过signal（）函数安装自己的处理函数。
处理函数可以通过sig_atomic_t类型的对象和外部进行通讯；如类型名所示，对这样的对象的操作是原子操作或者说中断安全的。
当你挂接信号处理函数时，通常提供一个函数地址，这个的函数必须接受一个整型值（所要处理的信号事件），并且无返回。
这样，信号处理函数有些象setjmp（）；它们所收到的仅有的异常信息是单个整数：
voidhandler（intsignal_value）;
voidf（void）
{
signal（SIGFPE,handler）;/*registerhandler*/
/*...*/
raise（SIGFPE）;/*invokehandler,passingit''''SIGFPE''''*/
}
只可其一地，你可以安装两个特别的处理函数：
l signal（SIGxxx,SIG_DFL），为指定的信号挂接系统的缺省处理函数。
l signal（SIGxxx，SIG_IGN），告诉系统忽略指定的信号。
signal（）函数返回前次挂接的处理函数的地址（表明挂接成功），或返回SIG_ERR（表明挂接失败）。
处理函数被调用表明信号正在试图恢复异常。
当然，你可以在处理函数中随意地调用abort（）、exit（）或longjmp（），有效地将信号解释为终止异常。
有趣的是，abort（）自己事实上在内部调用了raise（SIGABRT）。
SIGABRT的缺省处理函数发起了一个诊断并终止程序，当然你可以安装自己的处理函数来改变这个行为。
不能改变的是abort（）的终止程序的行为。
Abort（）理论上的实现如下：
voidabort（void）
{
raise（SIGABRT）;
exit（EXIT_FAILURE）;
}
也就是说，即使你的SIGABRT处理函数返回了，abort（）仍然中止你的程序。
C语言标准在信号处理函数的行为上增加了一些限制和解释。
如果你有C语言标准，我建议你查阅条款7.7.1.1的细节。
（很不幸，C语言和C++语言的标准在Internet都得不到。
）
的申明覆盖了异常的整个生存期，从产生到死亡。
在标准的C语言运行期库中，它们是最接近于异常完全解决方案的。
1.8 全局变量
和一般使用异常通知体系：
当试图通知一个异常事件时唤醒一个处理函数。
如果你更愿意使用轮询体系，C标准库在提供了例子。
这个头文件定义了errno及其一些可能的取值。
标准要求这样三个值：
EDOM、ERANGE和EILSEQ，分别适用于域、范围和多字节顺序错误，你的编译器可能又加了些其它的，它们全以字母“E”开头。
errno，通过由运行库的代码设置它而用户代码查询它的办法将二者联系起来，运行于异常生命期的1到3：
运行库产生异常对象（一个简单的整数），把值拷给errno，然后依赖用户的代码去轮询和检测这个异常。
运行库主要在和的函数中使用errno。
errno在程序开始时设为0，函数库程序不会再次把它设为0。
因此，要检测错误，你必须先将errno设为0，再调用运行库程序，调用完后检查errno的值：
#include
#include
#include
intmain（void）
{
doublex,y,result;
/*...somehowset''''x''''and''''y''''...*/
errno=0;
result=pow（x,y）;
if（errno==EDOM）
printf（"domainerroronx/ypair\n"）;
elseif（errno==ERANGE）
printf（"rangeerroronresult\n"）;
else
printf（"xtothey=%d\n",（int）result）;
return0;
}
注意：
errno不一定要绑在一个对象上：
int*_errno_function（）
{
staticintreal_errno=0;
return&real_errno;
}
#defineerrno（*_errno_function（））
intmain（void）
{
errno=0;
/*...*/
if（errno==EDOM）
/*...*/
}
你可以在自己的程序中采用这样的技巧，对errno及其值进行模拟。
使用C++的话，你当然可以把这种策略扩展到类或命名空间的对象和函数上。
（实际上，在C++中，这个技巧是SingletonPattern的基础。
）
1.9 返回值和回传参数
象errno这样的异常对象不是没有限制的：
l 所有相关联的部分必须一致，确保设置和检查同一个对象。
l 无关的部分可能意外地修改了对象。
l 如果没有在调用程序前重设对象，或在调用下一步前没有检查它们，你就可能漏了异常。
l 宏和内部代码中的对象在重名时将掩盖异常对象。
l 静态对象天生就不是（多）线程安全的。
总之，这些对象很脆弱：
你太容易用错它们，编译器没有警告程序却有不可预测的行为。
要排除这些不足，你需要这样的对象：
l 被两个正确的部分访问－－一个产生异常，一个检测
升级会员 