[Ace-users] [ace-users] C++ Exception handling model for Win32 builds

[Adrian Tulloch]

I see that recent (e.g. ACE 5.5 and ACE 5.6) Win32 builds of ACE are
compiled with the compiler option /EHa ("asynchronous exception
handling"). I was wondering whether it's worth considering changing this
to /EHsc ("synchronous exception handling").

To briefly recap the difference between these exception handling models,
asynchronous exception handling essentially means two things:
 a) The compiler must assume that any line of code could throw. This
prevents some optimizations.
 b) catch (...) catches OS-level faults (e.g. access violations).
By contrast, synchronous exception handling means that the compiler can
assume that only function calls or explicit throws throw an exception,
and catch(...) will only catches C++ exceptions.

As I understand, ACE deliberately decided to use asynchronous exception
handling. In particular, I saw this entry in the ace changelog:
  Tue Dec 6 18:40:12 UTC 2005 Johnny Willemsen <jwillemsen at remedy.nl>

   * bin/MakeProjectCreator/config/acedefaults.mpb:
     For vc8 set ExceptionHandling to 2. This enabled the structured
     exception handling. Normally vc8 doesn't catch structured
exceptions
     but we except so for some tests and else the disabling of the
     win32 error windows doesn't work. This fixes bugzilla [BUG:2290]
     See also http://www.codecomments.com/archive292-2005-8-578262.html
     for backgroup. Thanks to Steve Huston and Chad Elliott for
     proposing to handle this in this mpb file instead of in the vc8
     base mpc template 

I think it may be worth thinking a bit more about this change. Firstly,
as several people in that codecomments thread point out, catching
arbitrary faults in a catch(...) is generally a bad idea. Secondly (and
somewhat selfishly), this behaviour is causing some problems for the
system I'm working on. We depend on an external C library which handles
errors with a tradition "goto exit" style of coding. It seems that a
catch(...) in TAO means that access violations and other faults cause us
to jump straight into the catch block, without the C library having the
opportunity to clean up, leaving it in an invalid state.

So what would go wrong if we move to synchronous exception handling? Is
it just the reactor test? If so, then I'd suggest we change the test to
throw C++ exceptions instead of causing an access violation. Or do
people expect reactors to be swallow access violations and similar
faults?

Adrian