1.1 版本3：恢复异常
接下来，改：
__except(except_filter(3, EXCEPTION_CONTINUE_SEARCH))
为：
__except(except_filter(3, EXCEPTION_CONTINUE_EXECUTION))
重新编译并运行。可以看到这样的输出：
0:before first try
1: try
2: try
3: try
4: try
4: raising exception
3: filter => EXCEPTION_CONTINUE_EXECUTION
4: after exception
4: handling normal termination
3: continuation
2: continuation
2: handling normal termination
1: continuation
0:continuation
因为第三层的异常过滤器已经捕获了异常，第一层的过滤器不会被求值。捕获异常的过滤器求值为EXCEPTION_CONTINUE_EXECUTION，因此异常被恢复。异常处理函数不会被进入，将从异常发生点正常执行下去。
1.2 版本4：异常终止
这样的结构：
__try
{
/* ... */
return;
}
或：
__try
{
/* ... */
goto label;
}
__finally
{
/* ... */
}
/* ... */
label:
被认为是try块异常终止。以后调用AbnormalTermination()函数的话将返回非0值，就象异常仍然存在。
要看其效果，改这两行：
trace(4, "raising exception");
RaiseException(exception_code, 0, 0, 0);
为：
trace(4, "exiting try block");
goto end_4;
第4层的try块不是被一个异常结束的，现在是被goto语句结束的。运行结果：
0:before first try
1: try
2: try
3: try
4: try
4: exiting try block
4: handling abnormal termination
3: continuation
2: continuation
2: handling normal termination
1: continuation
0:continuation
第4层的终止处理函数认为它正在处理异常终止，虽然并没有发生过异常。（如果发生过异常的话，我们至少能从一个异常过滤器的输出信息上看出来的。）
结论：你不能只依赖AbnormalTermination()函数来判断异常是否仍存在。
1.3 版本5：正常终止
如果想正常终止一个try块，也就是想要AbnormalTermination() 函数返回FALSE，应该使用Microsoft特有的关键字__leave。想验证的话，改：
goto end_4;
为：
__leave;
重新编译并运行，结果是：
0:before first try
1: try
2: try
3: try
4: try
4: exiting try block
4: handling normal termination
3: continuation
2: continuation
2: handling normal termination
1: continuation
0:continuation
和版本4的输出非常接近，除了一点：第4层的终止处理函数现在认为它是在处理正常结束。
1.4 版本6：隐式异常
前面的程序版本处理的都是用户产生的异常。SEH也可以处理Windows自己抛出的异常。
改这行：
trace(4, "exiting try block");
__leave;
为：
trace(4, "implicitly raising exception");
*((char *) 0) = 'x';
这导致Windows的内存操作异常（引用空指针）。接着改：
__except(except_filter(3, EXCEPTION_CONTINUE_EXECUTION))
为：
__except(except_filter(3, EXCEPTION_EXECUTE_HANDLER))
以使程序捕获并处理异常。
执行结果为：
0:before first try
1: try
2: try
3: try
4: try
4: implicitly raising exception
3: filter => EXCEPTION_EXECUTE_HANDLER
4: handling abnormal termination
3: handling exception
2: continuation
2: handling normal termination
1: continuation
0:continuation
如我们所预料，Windows在嵌套层次4中触发了一个异常，并被层次3的异常处理函数捕获。
如果你想知道捕获的精确异常码，可以让异常传到main外面去，就象版本2中做的。为此，改：
__except(except_filter(3, EXCEPTION_EXECUTE_HANDLER))
为：
__except(except_filter(3, EXCEPTION_CONTINUE_SEARCH))
结果对话框在按了“Details”后，显示的信息非常象用户异常。
图3 内存异常对话框
和版本2的对话框不同是，上次显示了特别的异常码，这次说了“invalid page fault”－－更用户友好些吧。
1.5 C++考虑事项
在所有C兼容异常处理体系中，SEH无疑是最完善和最灵活的（至少在Windows环境下）。具有讽刺意味的，它也是Windows体系以外的环境中最不灵活的，它将你和特殊的运行平台及Visaul C++源码兼容的编译器牢牢绑在了一起。
如果只使用C语言，并且不考虑移植到Windows平台以外，SEH很好。但如果使用C++并考虑可移植性，我强烈建议你使用标准C++异常处理而不用SEH。你可以在同一个程序中同时使用SEH和标准C++异常处理，只有一个限制：如果在有SEH try块的函数中定义了一个对象，而这个对象又没有non-trivial（无行为的）析构函数，编译器会报错。在同一函数中同时使用这样的对象和SEH的__try，你必须禁掉标准C++异常处理。
（Visual C++默认关掉标准C++异常处理。你可以使用命令行参数/GX或Visual Studio的Project Settings对话框打开它。）
在以后的文章中，我会在讨论标准C++异常处理时回顾SEH。我想将SEH整合入C++的主流中，通过将结构化异常及Windows运行库支持映射为C++异常和标准C++运行库支持。
1.6 MFC异常处理
说明：这一节我需要预先引用一点点标准C++异常处理的知识，但要到下次才正式介绍它们。这个提前引用是不可避免的，也是没什么可惊讶的，因为Microsoft将它们的MFC异常的语法和语义构建在标准C++异常的语法和语义的基础上。
我到现在为止所讲的异常处理方法对C和C++都有效。在此之外，Microsoft对C++程序还有一个解决方案：MFC异常处理类和宏。Microsoft现在认为MFC异常处理体系过时了，并鼓励你尽可能使用标准C++异常处理。然而Visual C++仍然支持MFC异常类和及宏，所以我将给它个简单介绍。
Microsoft用标准C++异常实现了MFC3.0及以后版本。所以你必须激活标准C++异常才能使用MFC，即使你不打算显式地使用这些异常。前面说过，你必须禁掉标准C++异常来使用SEH，这也意味着你不能同时使用MFC宏和SEH。Microsoft明文规定这两个异常体系是互斥的，不能在同一程序中混合使用。
SEH是扩展了编译器关键字集，MFC则定义了一组宏：
l TRY
l CATCH, AND_CATCH, 和END_CATCH
l THROW 和 THROW_LAST
这些宏非常象C++的异常关键字try、catch和throw。
另外，MFC提供了异常类体系。所有名字为CXXXException形式的类都是从抽象类CException派生的。这类似于标准C++运行库在<setdxcept>中申明的从std::exception开始的派生体系。但，标准C++的关键字可以处理绝大部分类型的异常对象，而MFC宏只能处理CException的派生类型对象。
对于每个MFC异常类CXXXException，都有一个全局的辅助函数AfxThrowXXXException() ，它构造、初始化和抛出这个类的对象。你可以用这些辅助函数处理预定义的异常类型，用THROW处理自定义的对象（当然，它们必须是从CException派生的）。
基本的设计原则是：
l 用TRY块包含可能产生异常的代码。
l 用CATCH检测并处理异常。异常处理函数并不是真的捕获对象，它们其实是捕获了指向异常的指针。MFC靠动态类型来辨别异常对象。比较一下，SEH靠运行时查询异常码来辨别异常。
l 可以在一个TRY块上捆绑多个异常处理函数，每个捕获一个C++静态类型不同的对象。第一个处理函数使用宏CATCH，以后的使用AND_CATCH，用END_CATCH结束处理函数队列。
l MFC自己可能触发异常，你也可以显式触发异常（通过THROW或MFC辅助函数）。在异常处理函数内部，可以用THROW_LAST再次抛出最近一次捕获的异常。
l 异常一被触发，异常处理函数就将被从里到外进行搜索，和SEH时一样。搜索停止于找到一个类型匹配的异常处理函数。所有异常都是终止。和SEH不一样，MFC没有终止处理函数，你必须依赖于局部对象的析构函数。
一个小MFC例子，将大部分题目都包括了：
#include <stdio.h>
#include "afxwin.h"
void f()
{
TRY
{
printf("raising memory exception\n");
AfxThrowMemoryException();
printf("this line should never appear\n");
}
CATCH(CException, e)
{
printf("caught generic exception; rethrowing\n");
THROW_LAST();
printf("this line should never appear\n");
}
END_CATCH
printf("this line should never appear\n");
}
int main()
{
TRY
{
f();
printf("this line should never appear\n");
}
CATCH(CFileException, e)
{
printf("caught file exception\n");
}
AND_CATCH(CMemoryException, e)
{
printf("caught memory exception\n");
}
/* ... handlers for other CException-derived types ... */
AND_CATCH(CException, e)
{
printf("caught generic exception\n");
}
END_CATCH
return 0;
}
/*
When run yields
raising memory exception
caught generic exception; rethrowing
caught memory exception
*/
记住，异常处理函数捕获指向对象的指针，而不是实际的对象。所以，处理函数：
CATCH(CException, e)
{
// ...
}
定义了一个局部指针CException *e指向了被抛出的异常对象。基于C++的多态，这个指针可以引用任何从CException派生的对象。
如果同一try块有多个处理函数，它们按从上到下的顺序进行匹配搜索的。所以，你应该将处理最派生类的对象的处理函数放在前面，不然的话，更派生类的处理函数不会接收任何异常的（再次拜多态所赐）。
因为你典型地想捕获CException，MFC定义了几个CException特有宏：
l CATCH_ALL(e)和AND_CATCH_ALL(e)，等价于CATCH(CException, e)和AND_CATCH(CException, e)。
l END_CATCH_ALL ，结束CATCH_ALL... AND_CATCH_ALL队列。
l END_TRY等价于CATCH_ALL(e);END_CATCH_ALL。这让TRY... END_TRY中没有处理函数或说是接收所有抛出的异常。
这个被指的异常对象由MFC隐式析构和归还内存。这一点和标准C++异常处理函数不一样，MFC异常处理不会让任何人取得被捕获的指针的所有权。因此，你不能用MFC和标准C++体系同时处理相同的异常对象；不然的话，将导致内存泄漏：引用已被析构的对象，并重复析构和归还同一对象。
1.7 小结
MSDN在线还有另外几篇探索结构化异常处理和MFC异常宏的文章。
下次我将介绍标准C++异常，概述它们的特点及基本原理。我还会将它们和到现在已经看到的方法进行比较。
