synchronous vs. asynchronous exception model

[Javier Estrada]

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

[Carl Daniel [VC++ MVP]]

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.

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

[Ronald Laeremans [MSFT]]

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.nos pam>
wrote in message news:%2******** ********@tk2msf tngp13.phx.gbl. ..

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.

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

[Javier Estrada]

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

[Carl Daniel [VC++ MVP]]

Javier Estrada wrote:

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.
If you compile with /EHa there is no such 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.

To translate exceptions to C++ exceptions you need to compile with /EHa.
Under VC7{.1}, you can go through the motions of converting SE's to C++
exceptions (__set_se_handl er, etc), but in practice it won't work. Anywhere
the compiler optimized out the exception handling machinery, you translation
will just as effectively have been optimized out.

A couple things to be aware of when translating exceptions: First, you need
to call __set_se_handle r separately in each thread. Second, there's only
one handler per thread, so if some other library has already done it, you'll
wipe out their handler. Finally, the translator is called each time a
catch() block is evaluated and an SE is being processed (it's called by the
exception filter routine, in Win32 SEH terms). If you have deeply nested
try/catch structures, you may translate a single excepiton many times before
it's handled (or not). Look for articles on Matt Peitrek and a series by
Bobby Schmidt on MSDN for lots of details into how exception handling works
if you need more info.

IMO, there's no downside to /EHa except for slightly slower code in some
cases. If you're serious about catching and dealing with structured
exceptions, or interacting with code that uses structured exceptions, you
must use /EHa. As Ronald pointed out, any interaction with the CLR requires
/EHa. In fact, in VC++ 2005 this is enforced by the compiler - adding /clr
implicitly add /EHa and will cause an error if you try to use /EHs.

-cd

[Javier Estrada]

Thx. Very helpful information--thus the MVP title, eh?

[Gerhard Menzl]

Ronald Laeremans [MSFT] wrote:

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.

I find this rather hard to swallow. When creating a Managed C++ project,
the IDE will automatically set /clr and /EHsc. Does this mean that you
get incorrect compiler settings by default? And why do managed
exceptions seem to work in my application?

--
Gerhard Menzl

#dogma int main ()

Humans may reply by replacing the obviously faked part of my e-mail
address with "kapsch".

[Steve McLellan]

"Javier Estrada" <lj*******@hotm ail.com> wrote in message
news:eJ******** ******@TK2MSFTN GP10.phx.gbl...

Thx. Very helpful information--thus the MVP title, eh?

I always thought you had to climb tall mountains and meditate with wizened
gurus to get the MVPs.. that's my illusions shattered..

Steve

[Steve McLellan]

"Gerhard Menzl" <ge***********@ spamspamspamlov elyspam.net> wrote in message
news:41******** @news.kapsch.co .at...

Ronald Laeremans [MSFT] wrote:

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.

I find this rather hard to swallow. When creating a Managed C++ project,
the IDE will automatically set /clr and /EHsc. Does this mean that you get
incorrect compiler settings by default? And why do managed exceptions seem
to work in my application?

I also didn't know about this, and it seems a rather dangerous omission. I
don't know of any problems we've had NOT using /EHa, however. There also
doesn't appear to be any option in the IDE to enable /EHa - which means that
the development team either didn't have a lot of problems not using it, or
added it programmaticall y to the command line but didn't add it to the IDE
for whatever reason?

Steve

[Carl Daniel [VC++ MVP]]

Gerhard Menzl wrote:

Ronald Laeremans [MSFT] wrote:

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.

I find this rather hard to swallow. When creating a Managed C++
project, the IDE will automatically set /clr and /EHsc. Does this
mean that you get incorrect compiler settings by default? And why do
managed
exceptions seem to work in my application?

That's what it means, yes - MC++ projects created by VC++ 2003 don't handle
exceptions properly.

Unless you produce a construct in which an unmanaged object exists in a
stack frame above the point at which a managed exception is raised and below
the frame where the managed exception is caught and the exception frame in
which that unmanaged obect was optimized away, you'll never see a problem.

So it's a pretty special case that doesn't work. If your calling pattern is
always managed -> native and never vice-versa, I don't think you'd ever see
a problem.

-cd