synchronous vs. asynchronous exception model

  • Thread starter Thread starter Javier Estrada
  • Start date Start date
J

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
 
Javier said:
Can someone explaing the difference between these exception models
regarding the structured exception handling? The documentation is
not clear. Some code would actually help.
Click to expand...

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
 
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
 
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
 
Javier said:
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.
Click to expand...

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.
Click to expand...

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
 
Ronald said:
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.
Click to expand...

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".
 
Javier Estrada said:
Thx. Very helpful information--thus the MVP title, eh?
Click to expand...

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

Steve
 
Gerhard Menzl said:
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?
Click to expand...

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
 
Gerhard said:
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?
Click to expand...

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
 
Steve said:
I always thought you had to climb tall mountains and meditate with
wizened gurus to get the MVPs.. that's my illusions shattered..
Click to expand...

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

-cd
 
Steve said:
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?
Click to expand...

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
 
Carl said:
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,
Click to expand...

....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.
Click to expand...

-cd
 
Carl Daniel [VC++ MVP] wrote:

replace __set_se_handler with _set_se_translator throughout the posting
above.

-cd
 
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.
Click to expand...
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
 
Carl said:
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.
Click to expand...

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".
 
Back
Top