Mar*_*rkS 16 c++ exception seh access-violation visual-studio-2008
如果我在非托管C++,Visual Studio 2008或更高版本中创建一个新项目,我想要使用哪种异常处理模型？
我知道/ EHa选项导致代码效率降低,并且还会捕获SEH异常,对吧？
所以我一直在转向那个选项,并且通常使用/ EHsc,因此我只捕获实际抛出的C++异常,而不是捕获访问冲突和其他结构化的execse,在catch(...)处理程序中.如果我的代码中存在访问冲突,我不希望它被catch(...){}掩盖.
我和其他想要捕获(...){}的人一起编写代码,如果存在访问冲突,他们甚至希望它这样做,这对我来说似乎是一个非常糟糕的主意.如果由于编码错误而导致错误,您不想将手指伸入耳中并大声说"La la la la la!" 这样你就不必让程序崩溃了？事实上,如果代码由于编码错误现在处于错误状态,您真的希望代码继续吗？
所以我的一般想法是/ EHa创建更大/更慢的代码并且它允许程序员逃避编写代码,如果存在致命错误,它将继续以未定义状态运行.
顺便说一下,我说的是应用程序和服务代码,这是我们大部分时间写的.不是低级设备驱动程序或类似的东西.
请考虑一下你的想法.
Han*_*ant 20
/ EHa做了两件事.首先,它抑制了一个优化,如果代码分析器看不到任何可能引发C++异常的代码,则省略异常过滤器会自动调用本地类变量的析构函数.这使得堆栈展开对于任何类型的异常都是安全的,而不仅仅是C++异常.这些异常过滤器的开销是x86上的时间和x86和x64上的空间.
是的,它改变了catch(...)的行为,它现在也过滤了任何SEH异常,而不仅仅是C++.这确实是一场赌博,因为你抓住了所有非常讨厌的东西,即异步硬件异常.虽然我个人并不认为捕获所有C++异常也是非常可靠的,但是你仍然只有一个模糊的想法,即程序状态在何种程度上发生变异以及失败的原因.
实际上,您需要切换到使用,__try/__except以便您可以编写自己的异常过滤器并避免捕获坏的过滤器.C++异常的异常代码是0xe04d5343("MSC").使用_set_se_translator()将是另一种方法.
我使用/ EHa是因为它与.NET互操作是安全的，而/ EHsc可能不是。请参见例如当本机（C ++）异常传播到CLR组件时未调用的析构函数。
但是，如果对于特定的代码额外的性能确实很重要，并且您不需要.NET（或其他任何方式）兼容性，那么可以肯定，/ EHsc听起来不错。
/ EHsc和/ EHa都不能捕获大多数内存错误，因此使用这些错误来捕获访问冲突是没有希望的情况。