处理C与C++中的异常问题的步骤

1. Microsoft对异常处理方法的扩展

前次，我概述了异常的分类和C标准库支持的处理方法。这次讨论Microsoft对这些方法的扩展：结构化异常处理（SEH）和Microsoft Foundation Class （MFC）异常处理。SEH对C和C++都有效，MFC异常体系只对C++有效。

1.1 机构化异常处理

机构化异常处理是Windows提供的服务功能并对所有语言写的程序有效。在Visual C++中，Microsoft封装和简化了这些服务（通过非标准的关键字和库程序）。Windows平台的其它编译器可能选择不同的方式来到达相似的结果。在这个专栏中，名词“Structured Exception Handling”和“SEH”专指Visual C++对Windows异常服务的封装。

1.2 关键字

为了支持SEH，Micorsoft用四个新关键字扩展了C和C++语言：

l __except

l __finally

l __leave

l __try

因为这是非标关键字，必须打开扩展选项后再编译（关掉/Fa）。

为什么这些关键字带下划线？C++标准（条款17.4.3.1.2，“Global names”）规定：

下列名字和函数总是保留给编译器：

l 所有带双下划线（__）或以一个下划线加一个大写字母开始的名字保留给编译器随意使用。

l 所有以一个下划线开始的名字保留给编译器作全局名称用。

C标准有类似的申明。

既然SEH的关键字符合上面的规则，Microsoft就有权这样使用它们。这也表明，你不被允许在自己的程序中使用保留的名字。你必须避免定义名字类似__MYHEADER_H__或_FatalError的标识符。

有趣而又不幸地，Visual C++的application wizards产生的源代码使用了保留的标识符。例如，如果你用ATL COM App Wizard生成一个新的service，结果框架代码定义了如_Handler和_twinMain的名字－－标准所说的你的程序不能使用的保留名称。

要减少这个不合规定行为，你当然可以手工更改这些名称。还好，这些有疑问的名字都是类的私有变量，在类的定义外面是不可见的，在.h和.cpp中进行全局替换是可行的。不幸的是，有一个函数（_twinMain）和一个对象（_Module）被申明了extern，也就是说程序的其它部分会假定你使用了这些名字。（事实上，Visual C++库libc.lib在连接时需要名字_twinMain可用。）

我建议你保留Wizard生成的名字，不要在你自己的代码中定义这样的名字就可以了。另外，你应该将所有不合标准的定义写入文档并留给程序的维护人员；记住，Visual C++以后的版本（和现有的其它C++编译器）可能以另外的方式使用这些名字，从而破坏了你的代码。

1.3 标识符

Microsoft也在非标头文件excpt.h中定义了几个SEH的标识符，并且包含入windows.h中。在其内部，定义了：

l 供__except的过滤表达式使用的过滤结果宏。

l Win32对象和函数的别名宏，用于查询异常信息和状态。

l 伪关键字宏，和前面谈到的四个关键字有着相同名字和含义，但没有下划线。（例如，宏leave对应SEH关键字__leave。）

Microsoft用这些宏令我抓狂。他们对同一个函数了定义多个别名。例如，excpt.h有如下申明和定义：

unsigned long __cdecl _exception_code(void);

#define GetExceptionCode _exception_code

#define exception_code _exception_code

也就是说，你可以用三种方法调用同一函数。你用哪个？并且，这些别名会如你所期望地被维护吗？

在Microsoft的文档中，它看起来偏爱GetExceptionCode，它的名字和其它全局Windows API函数风格一致。我在MSDN中搜索到33处GetExceptionCode，两个_exception_code，而exception_code个数为0。根据Microsoft的引导，推荐使用GetExceptionCode及类似名称的其它函数。

因为_exception_code的两个别名是宏，所以你不能再使用同样的名字了。我曾经犯过这个错，当我在为这个专栏写例程的时候。我定义了一个局部对象叫exception_code（大概是吧）。实际上我就是定义了一个局部对象叫_exception_code，这是我无意中使用的宏exception_code展开的结果。当我一想到是这个问题，解决方案就是简单地将我的对象名字从exception_code改为code。

最后，excpt.h定义了一个特别的宏－－“try”－－已经成为C++真正的关键字的东西。这意味着你不能在包含了excpt.h的编译单元中简单地混合SEH和标准C++的异常块，除非你愿意#undef这个try宏。当这样undef而露出真正的try关键字时，要冒搞乱SEH的维护人员大脑的危险。另一方面，精通标准C++的程序员会将try理解为一个关键字而不是宏。

我认为，包含一个头文件（即使是象excpt.h这样的非标头文件）不应该改变符合语言标准的代码的行为。我更坚持掩盖或重定义掉语言标准定义的关键字是个坏习惯。我建议：＃undef try，同样不使用其它的伪关键字宏，直接使用真正的关键字（如__try）。

1.4 语法

最基本的SEH语法是try块。如下形式：

__try compound-statement handler

处理体：

__except ( filter-expression ) compound-statement

或：

__finally compound-statement

完整一点看，try块如下：

__try

{

...

}

__except(filter-expression)

{

...

}

或：

__try

{

...

}

__finally

{

...

}

在__try里面你必须使用一个leave语句：

__try

{

...

__leave;

...

}

在更大的程序块中，一个try块被认为是个单条语句：

if (x)

{

__try

{

...

}

__finally

{

...

}

}

等价于：

if (x)

__try

{

...

}

__finally

{

...

}

其它注意点：

l 在给定的try块中你必须有一个正确的异常处理函数。

l 所有的语句必须合并。即使只有一条语句跟在__try、__except或__finally后面也必须将它放入{}中。

l 在异常处理函数中，相应的过滤表达式必须有一个或能转换为一个int型的值。

1.5 基本语意

上次我列举了异常生命期的5个阶段。在SEH体系下，这些阶段实现如下：

l 操作系统上报了一个硬件错误或检测到了一个软件错误，或用户代码检测到一个错误（阶段1）。

l （通常是由用户调用Win32函数RasieException启动，）操作系统产生并触发一个异常对象（阶段2）。这个对象是一个结构，其属性对异常处理函数可见。

l 异常处理函数“看到”异常，并且有机会捕获它（阶段3和4）。取决于处理函数的意愿，异常将或者恢复或者终止。（阶段5）。

一个简单的例子：

int filter(void)

{

/* Stage 4 */

}

int main(void)

{

__try

{

if (some_error) /* Stage 1 */

RaiseException(...); /* Stage 2 */

/* Stage 5 of resuming exception */

}

__except(filter()) /* Stage 3 */

{

/* Stage 5 of terminating exception */

}

return 0;

}

Microsoft调用定义在__except中的异常处理函数，和定义在__finally中的终止函数。

一旦异常被触发，由__except开始的异常处理函数被异常发生点顺函数调用链向外面询问。每个被发现的异常处理函数，其过滤表达式都被求值。每次求值后发生什么取决于其返回结果。

excpt.h定义了3个过滤结果的宏，都是int型的：

l EXCEPTION_CONTINUE_EXECUTION = -1

l EXCEPTION_CONTINUE_SEARCH = 0

l EXCEPTION_EXECUTE_HANDLER = 1

前面我说过，过滤表达式必须兼容int型，所以它们和这3个宏的值匹配。这个说法太保守了：我的经验显示Visual C++接受的过滤表达式可以具有所有的整型、指针型、结构、数组甚至是void型！（但我在尝试浮点指针时遇到了编译错误。）

更进一步，所有求出的值看来都有效（至少对整型如此）。所有非零且符号位为0的值效果相当于EXCEPTION_EXECUTE_HANDLER，而符号位为1的相当于EXCEPTION_CONTINUE_EXECUTION。这大概是按位取模的结果。

如果一个异常处理函数的过滤求值结果是EXCEPTION_CONTINUE_SEARCH，这个处理函数拒绝捕获异常，将继续搜索下一个异常处理函数。

通过由过滤表达式产生一个非EXCEPTION_CONTINUE_SEARCH来捕获异常，一旦捕获，程序就恢复。怎么恢复仍然由过滤表达式的值决定：

l EXCEPTION_CONTINUE_EXECUTION：表现为恢复异常。从发生异常处下面开始执行。异常处理函数本身的代码不执行。

l EXCEPTION_EXECUTE_HANDLER：表现为终止异常。从异常发生处开始退栈，一路上所遇到终止函数都被执行。栈退到捕获异常的处理函数所在的一级为止。进入处理函数体并执行。

如名所示，终止处理函数（以__finally开始的代码）在终止异常时被调用。里面是clean up代码，它们就象C标准库中的atexit()函数和C++的析构函数。终止处理函数在正常执行流程也会进入，就象不是捕获型代码。相反，异常处理函数总表现为捕获型：它们只在其过滤表达式求值为EXCEPTION_EXECUTE_HANDLER时才进入。

终止处理函数并不明确知道自己是从正常流程进入的还是在一个try块异常终止时进入的。要判断这点，可以调用AbnormalTermination函数。此函数返回一个int，0表明是从正常流程进入的，其它值表明在异常终止时进入的。

AbnormalTermination实际上是个指向_abnormal_termination()的宏。Visual C++将_abnormal_termination()设计为环境敏感的函数，就象一个关键字。你不能随便调用这个函数，只能在终止处理函数中调用。这意味着你不能在终止处理函数中调用一个中间函数，再在此中间函数中调用_abnormal_termination()，这样做会得到一个编译期错误。

1.6 例程

下面的C例子显示了不同的过滤表达式值和处理函数本身类型的相互作用。第一个版本是个小的完整程序，以后的版本都在它前面一个上有小小的改动。所有的版本都自解释的，你能看清流程和行为。

程序通过RaiseException()触发一个异常对象。RaiseException()函数的第一个参数是异常的代码，类型是32位无符号整型（DWORD）；Microsoft为用户自定义的错误保留了[0xE0000000,0xEFFFFFFF]的范围。其它参数一般填0。

这里使用的异常过滤器很简单。实际使用中，大概要调用GetExceptionCode()和GetExceptionInformation()来查询异常对象的属性。

1.7 Version #1: Terminating Exception

用Visual C++生成一个空的Win32控制台程序，命名为SEH_test，选项为默认。将下列C源码加入工程文件：

#include <stdio.h>

#include "windows.h"

#define filter(level, status) /

( /

printf("%s:%*sfilter => %s/n", /

#level, (int) (2 * (level)), "", #status), /

(status) /

)

#define termination_trace(level) /

printf("%s:%*shandling %snormal termination/n", /

#level, (int) (2 * (level)), "", /

AbnormalTermination() ? "ab" : "")

static void trace(int level, char const *message)

{

printf("%d:%*s%s/n", level, 2 * level, "", message);

}

extern int main(void)

{

DWORD const code = 0xE0000001;

trace(0, "before first try");

__try

{

trace(1, "try");

__try

{

trace(2, "try");

__try

{

trace(3, "try");

__try

{

trace(4, "try");

trace(4, "raising exception");

RaiseException(code, 0, 0, 0);

trace(4, "after exception");

}

__finally

{

termination_trace(4);

}

end_4:

trace(3, "continuation");

}

__except(filter(3, EXCEPTION_CONTINUE_SEARCH))

本文地址：http://www.45fan.com/dnjc/73612.html