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

[Johnny Willemsen]

Hi,

We also need this setting for the ACE_DISABLE_WIN32_ERROR_WINDOWS to work.
We use this on all build systems to log access violations to a file instead
of getting something on the screen. Can't you just override the default in
your default.features file and regenerate the project files?

Regards,

Johnny Willemsen
Remedy IT
Postbus 101
2650 AC  Berkel en Rodenrijs
The Netherlands
www.theaceorb.nl / www.remedy.nl  

*** Integrated compile and test statistics see
http://scoreboard.theaceorb.nl ***
*** Commercial service and support for ACE/TAO/CIAO             ***
*** See http://www.theaceorb.nl/en/support.html                 ***

> 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
> 
> _______________________________________________
> ace-users mailing list
> ace-users at mail.cse.wustl.edu
> http://mail.cse.wustl.edu/mailman/listinfo/ace-users
>