前些时候，在论坛上看到一个朋友说SEH怎么怎么不好，一定不要用它。其实存在即合理。就像GOTO，不能因为它破坏了程序的流程，就不用它，适当的使用，还是可以事半功倍的。

大家知道SEH是Windows操作系统提供的一种异常处理机制，它和C++无关。在Compiler编译的时候，就把这个机制加入了我们的程序中。在VC下可以用__try, __finally, __except, __leave等关键字来标识。由于SEH可以捕获硬件异常(Hardware Exception)和软件异常(Software Exception)，它比C++的异常机制能捕获更多的异常，所以有朋友不喜欢这点，认为它掩盖了错误。其实这种说法是也是合情合理的，毕竟掩盖错误不是最好的解决方案，找出问题的所在才是我们应该做的。可是在现实中，我们不可能找到所有的bug，或者由于时间的关系，来不及修补这个bug，不如先用SEH挡一挡，何尝不可。

就像我之前的一个项目，程序在一个地方偶尔会Crash掉，而且这个地方如果不能正常执行丝毫不影响整个程序的运作，不会对用户造成损失，在找出问题真正的原因之前，我们完全可以用SEH捕获异常。

 下面的例子也是一个SEH优势的体现

BOOL SafeDiv(INT32 dividend, INT32 divisor, INT32 *pResult)
{
    __try
    {
        *pResult = dividend / divisor;
    }
    __except(GetExceptionCode() == EXCEPTION_INT_DIVIDE_BY_ZERO ?
             EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH)
    {
        return FALSE;
    }
    return TRUE;
}

SafeDiv用来做除法操作，它的返回值指出函数是否执行成功。pResult指向最终的结果，如果不用SEH，这类Hardware Exception会导致程序Crash，这里引入了SEH，我们在发现有除零错误的时候，让函数返回FALSE，调用处通过检查函数的返回值就可以判断除法运算是否成功，没必要就因为一个除零错误导致程序Crash掉。

由于SEH是Windows操作系统特有的机制，所以它不适合用在那些跨平台的代码，这种情况不用也罢，既然SEH是一个Windows的一个很好的异常处理机制，我们虽不能滥用它，适当的、合理的使用还是值得推荐的。

P.S.
For details about SEH, check this: http://www.google.com/search?hl=en&q=Programming+Applications+for+Microsoft+Windows