[Ace-users] [ace-users] C++ Exception handling model for Win32 builds
jwillemsen at remedy.nl
Wed Dec 12 00:14:16 CST 2007
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?
2650 AC Berkel en Rodenrijs
www.theaceorb.nl / www.remedy.nl
*** Integrated compile and test statistics see
*** 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
> 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
> 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
> 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
> ace-users mailing list
> ace-users at mail.cse.wustl.edu
More information about the Ace-users