发布时间：2010-12-20 23:14
分类名称：SEH
Visual C++ 支持3种类型的异常处理：
1. C++ exception handling
C++标准规范中指定的异常处理机制。C++编程，使用该机制。
关键字：try, catch, throw
2. Structured exception handling
Windows 特有的异常处理机制（SEH）。It is not recommended for C++ or MFC programming. Use SEH only in non-MFC C programs.
关键字：__try, __except, __leave, __Finally,
3. MFC exception
Since version 3.0, MFC has used C++ exceptions but still supports its older exception handling macros, which are similar to C++ exceptions in form. The older MFC exception handling macros have been supported since version 1.0. Although these macros are not recommended for new programming, they are still supported for backward compatibility. In programs that already use the macros, you can freely use C++ exceptions as well. During preprocessing, the macros evaluate to the exception handling keywords defined in the Visual C++ implementation of the C++ language as of Visual C++ version 2.0. You can leave existing exception macros in place while you begin to use C++ exceptions.
MFC 使用的也就是C++ exception handling.只是MFC历史悠久，比发明异常处理都久，所以第一代MFC使用宏，自己来实现异常处理。
Visual C++ 针对这俩张不同的异常处理，制定了两种模型：
n synchronous exception handling model (C++ exception handling without structured exception handling exceptions)
n asynchronous exception handling model ((C++ exception handling with structured exception handling exceptions)
有编译选项：/EH{s|a}[c][-] 来控制。
然而同步模型在VC6 ~ VC .NET 2003之间，存在Bug，支持不完善，所以会出现在此模型中，可以获取SE错误（系统级别的错误，不是throw语句抛出的，比如说除零）。例如在没有被优化的代码中（如Debug版本）或你编译的代码虽然被优化，但是优化器无法判断一段代码是否会抛出异常。例如VC5中，如果在try块中调用函数，那么编译器就断定此函数会抛出异常。而到了VC6，如果这个函数在其他的cpp文件中实现的，结果可能无法预料。到了VC .NET 2005，就修正这个问题。
C++异常和Win32异常是俩个不同的异常。 当可以同时获取系统异常和C++异常时，会有些问题。
1. 如果catch (…)可以捕获SEs，下面的代码中：
// Begin exception-free code
... Update critical data structure
// End exception-free code
catch (…) 语句捕获到SE，那么程序将处于无法预料的状态中。程序可能卡住一段时间。如果你比较幸运，接下的没有被捕获到的SE会在没有产生很严重破坏的时候结束。这使得调试起来很困难，第二个SE和第一个SE可能代码可能离得很远。
2. 下面的代码让人不能确信是否正确：
try
{
TheFastButResourceHungryWay();
}
catch (...)
{
TheSlowButSureWay();
}
如果在TheFastButResourceHungryWay中，产生非法访问，catch却捕获到错误，使得你失去发现错误的机会，或者只是出现程序运行时有点莫名其妙的缓慢现象。（可能你并察觉不到）。而如果catch不捕获的话，操作系统就会蹦出一个框，你就发现错误存在的地方了。
3. The normal operation of the system is impaired.
For example, the MFC CPropertySheet::DoModal () documentation describes a scenario in which you should not use catch(...). The exception raised by the DebugBreak API can be caught by catch (...), rendering DebugBreak useless. Also, if you're using __try/__except to handle SEs properly, you may have trouble if an interior catch (...) is present, even if it rethrows. You almost certainly will have trouble if your SE handler resumes execution with the faulting instruction. You may find the catch (...) block was entered and local variables destroyed, which is very bad if execution is resumed in its complementary try block. And if that try block subsequently throws a C++ exception, you may find yourself in an infinite loop with your SE filter function.
4. Application frameworks are taking a chance if they guard your code with catch(...), which they normally should do. For example, MFC does not use catch(...), and as a result, an uncaught C++ exception terminates an MFC application Asdf
所以在Vistual C++ 5 到2003中，避免使用catch (…). 除非你觉得上面说的对你来说都不是什么问题。如果使用2005以上的版本， /EHs已经很好解决了这个问题，在synchronous exception handling model中，catch (…)，是不会捕获到SEs的。