Visual C ++非托管代码：使用/ EHa或/ EHsc进行C ++异常？

Question

如果我在非托管C ++，Visual Studio 2008或更高版本中创建一个新项目，我想要使用哪种异常处理模型？

我知道/ EHa选项导致代码效率降低，并且还会捕获SEH异常，对吗？

所以我一直在转向那个选项，并且通常使用/ EHsc，因此我只捕获实际抛出的C ++异常，而不是捕获访问冲突和其他结构化的execse，在catch（...）处理程序中。如果我的代码中存在访问冲突，我不希望它被catch（...）{}掩盖。

我和其他想要捕获（...）{}的人一起编写代码，如果存在访问冲突，他们甚至希望它这样做，这对我来说似乎是一个非常糟糕的主意。如果由于编码错误而导致错误，您不想将手指伸入耳中并大声说“La la la la la！”这样你就不必让程序崩溃了？事实上，如果代码由于编码错误现在处于错误状态，您真的希望代码继续吗？

所以我的一般想法是/ EHa创建更大/更慢的代码，它允许程序员逃避编写代码，如果存在致命错误，它将继续以未定义状态运行。

顺便说一句，我在谈论应用程序和服务代码，这是我们大部分写的。不是低级设备驱动程序或类似的东西。

请考虑你的想法。

Answer 1

/ EHa做了两件事。首先，如果代码分析器看不到任何可能引发C ++异常的代码，它会抑制省略异常过滤器的优化，该异常过滤器会自动调用本地类变量的析构函数。这使得堆栈展开对于任何类型的异常都是安全的，而不仅仅是C ++异常。这些异常过滤器的开销是x86上的时间和x86和x64上的空间。

是的，它改变了catch（...）的行为，它现在也过滤了任何SEH异常，而不仅仅是C ++。这确实是一场赌博，因为你抓住了所有非常讨厌的东西，即异步硬件异常。虽然我个人并不认为捕获所有C ++异常也是非常可辩护的，但是你仍然只有一个模糊的想法，即程序状态变异的程度以及失败的原因。

实际上，您需要切换到使用__try/__except，以便您可以编写自己的异常过滤器并避免捕获坏的过滤器。 C ++异常的异常代码是0xe04d5343（“MSC”）。使用_set_se_translator（）将是另一种方法。

Answer 2

我使用/ EHa因为它与.NET互操作是安全的，而/ EHsc可能不是;例如，请参阅Destructors not called when native (C++) exception propagates to CLR component。

但是，如果对于特定的代码，额外的性能真的很重要，并且您不需要.NET（或其他任何）兼容性，那么/ EHsc听起来不错。

/ EHsc和/ EHa都没有捕获大多数内存错误，因此使用这些来捕获访问冲突是一个绝望的案例。