同步与异步异常模型 [英] synchronous vs. asynchronous exception model

问题描述

有人可以解释这些关于

的异常模型之间的区别结构化异常处理吗？文件不清楚。一些

代码实际上会有所帮助。


Thx

Can someone explaing the difference between these exception models regarding
the structured exception handling? The documentation is not clear. Some
code would actually help.

Thx

推荐答案

Javier Estrada写道：

Javier Estrada wrote:

有人可以解释这些异常模型之间关于结构化异常处理的区别吗？文件不清楚。有些代码实际上会有所帮助。

Can someone explaing the difference between these exception models
regarding the structured exception handling? The documentation is
not clear. Some code would actually help.

不同之处在于编译器假设可以抛出异常

的假设。在同步模型下，只有throw语句可以
导致抛出异常。在异步模型下，任何

指令都会导致异常被抛出。


因此，在同步模型下，编译器可以省略

异常处理代码区域中可以证明没有异常可以抛出
（由于缺少throw语句），而在异步模型下，

所有异常处理机制都是一直需要的。


如果你正在编写需要处理原生的（需要处理Win32结构化）的C ++代码

例外，您应该使用/ EHa进行编译。如果你不这样做，可能会出现这样的情况：带有自动存储的对象（即基于堆栈）在引发本机异常时，它们的析构函数没有调用。


-cd

The difference lies in assumptions the compiler makes about where exceptions
can be thrown. Under the synchronous model, only throw statements can
result in an exception being thrown. Under the asynchronous model, any
instruciton can result in an exception being thrown.

As a result, under the synchronous model, the compiler can leave out
exception handling code in areas where it can prove that no exception can be
thrown (due to the lack of throw statements), while under the async model,
all of the exception handling machinery is required all the time.

If you''re writing C++ code that needs to handle native (Win32 Structured)
exceptions, you should be compiling with /EHa. If you don''t, there may be
cases where objects with automatic storage (i.e. stack based) do not have
their destructors called when a native exception is raised.

-cd

如果用/ clr编译调用树的部分，则需要使用

/ EHa以及CLR使用SEH异常作为其基本机制。


Ronald Laeremans

Visual C ++团队


" Carl Daniel [VC ++ MVP]" < cp ***************************** @ mvps.org.nospam>

写道消息新闻：％2 **************** @ tk2msftngp13.phx.gbl ...

And if you are compiling parts of your call tree with /clr you need to use
/EHa as well since the CLR uses SEH exceptions as its underlying mechanism.

Ronald Laeremans
Visual C++ team

"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:%2****************@tk2msftngp13.phx.gbl...

Javier Estrada写道：

Javier Estrada wrote:

有人可以解释这些异常模型之间关于结构化异常处理的区别吗？文件不清楚。有些代码实际上会有所帮助。

Can someone explaing the difference between these exception models
regarding the structured exception handling? The documentation is
not clear. Some code would actually help.

不同之处在于编译器假设可以抛出异常的假设。在同步模型下，只抛出
语句可能导致抛出异常。在异步模型下，任何一个指令都会导致异常被抛出。

因此，在同步模型下，编译器可以省略
异常在可以证明不会抛出任何异常的区域中处理代码（由于缺少throw语句），而在async
模型下，所有异常处理机制都是一直需要的。

如果您正在编写需要处理本机（Win32 Structured）异常的C ++代码，那么您应该使用/ EHa进行编译。如果你不这样做，可能会有这样的情况：自动存储的对象（即基于堆栈）没有在引发本机异常时调用它们的析构函数。

-cd

The difference lies in assumptions the compiler makes about where
exceptions can be thrown. Under the synchronous model, only throw
statements can result in an exception being thrown. Under the
asynchronous model, any instruciton can result in an exception being
thrown.

As a result, under the synchronous model, the compiler can leave out
exception handling code in areas where it can prove that no exception can
be thrown (due to the lack of throw statements), while under the async
model, all of the exception handling machinery is required all the time.

If you''re writing C++ code that needs to handle native (Win32 Structured)
exceptions, you should be compiling with /EHa. If you don''t, there may be
cases where objects with automatic storage (i.e. stack based) do not have
their destructors called when a native exception is raised.

-cd

好吧，看起来两种方式都不好，不是吗。


一方面，假设只有throw语句会导致

异常是荒谬的。


我需要编写C ++代码应对SEH（例如，访问无效指针，

等）。但是，拥有自动存储的对象未被破坏会带来另一种风险。


将SEH异常转换为C ++异常是否有帮助？我刚刚读了一篇关于替换异常的代码项目的文章，但最后它还建议使用变通方法或异步模型。


Thx

Well, it seems like it''s bad both ways, isn''t it.

On one hand, the assumption that only throw statements will result in an
exception is ridiculous.

I need to write C++ code to cope with SEH (e.g., accessing invalid pointers,
etc.). However, having objects with automatic storage undestroyed poses yet
another risk.

Does translating the SEH exceptions to C++ exceptions help in any way? I
just read an article on The Code Project on replacing the exceptions, but at
the end it also recommends using a workaround or the asynchronous model.

Thx

这篇关于同步与异步异常模型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！