By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,544 Members | 2,002 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,544 IT Pros & Developers. It's quick & easy.

synchronous vs. asynchronous exception model

P: n/a
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
Nov 17 '05 #1
Share this Question
Share on Google+
15 Replies


P: n/a
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
Nov 17 '05 #2

P: n/a
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 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

Nov 17 '05 #3

P: n/a
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


Nov 17 '05 #4

P: n/a
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_handler, 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_handler 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
Nov 17 '05 #5

P: n/a
Thx. Very helpful information--thus the MVP title, eh?
Nov 17 '05 #6

P: n/a
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".
Nov 17 '05 #7

P: n/a
"Javier Estrada" <lj*******@hotmail.com> wrote in message
news:eJ**************@TK2MSFTNGP10.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
Nov 17 '05 #8

P: n/a
"Gerhard Menzl" <ge***********@spamspamspamlovelyspam.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 programmatically to the command line but didn't add it to the IDE
for whatever reason?

Steve
Nov 17 '05 #9

P: n/a
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
Nov 17 '05 #10

P: n/a
Steve McLellan wrote:
"Javier Estrada" <lj*******@hotmail.com> wrote in message
news:eJ**************@TK2MSFTNGP10.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..


The mountain-climbing does help... ;-)

-cd
Nov 17 '05 #11

P: n/a
Steve McLellan wrote:
"Gerhard Menzl" <ge***********@spamspamspamlovelyspam.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 programmatically to
the command line but didn't add it to the IDE for whatever reason?


I believe you have to add it explicitly to the command line in the IDE.
This is fixed in Whidbey - /EHa is added authomatically, and attempting to
compile with /clr /EHs produces an error.

See my other reply (to Gerhard Menzl) for why you've probably never noticed
anything not working.

-cd
Nov 17 '05 #12

P: n/a
Carl Daniel [VC++ MVP] wrote:
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,
....and the destructor of the native object does something important enough
that you'd notice if it wasn't called...
you'll never see a problem.


-cd
Nov 17 '05 #13

P: n/a
Carl Daniel [VC++ MVP] wrote:

replace __set_se_handler with _set_se_translator throughout the posting
above.

-cd
Nov 17 '05 #14

P: n/a
>>>
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 programmatically to
the command line but didn't add it to the IDE for whatever reason?


I believe you have to add it explicitly to the command line in the IDE.
This is fixed in Whidbey - /EHa is added authomatically, and attempting to
compile with /clr /EHs produces an error.

See my other reply (to Gerhard Menzl) for why you've probably never
noticed anything not working.

Have done, and yes, it probably does explain it. Presumably none of the MS
engineers came across it either (or they're not telling). Good to know (as
per usual) that "it's fixed in the next version" :-)

Thanks,

Steve
Nov 17 '05 #15

P: n/a
Carl Daniel [VC++ MVP] wrote:
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.


Hm, I have managed objects that contain Standard Library containers of
(gcrooted) managed objects that may throw. And our release-or-perish
deadline is a mere fortnight away.

Words like "creeps" or "heebie-jeebies" come to mind ...

--
Gerhard Menzl

#dogma int main ()

Humans may reply by replacing the obviously faked part of my e-mail
address with "kapsch".
Nov 17 '05 #16

This discussion thread is closed

Replies have been disabled for this discussion.