From: carlos pizano (carlospizano_at_[hidden])
Date: 2003-09-21 00:43:52
Carl Daniel wrote:
>_set_se_translator works just fine in release builds.
Agree. I don't know what is that all about. The book does not elaborate
> This is true. If, that is, you're relying on proper C++ unwinding
> when an SEH is raised. With /EHs, _set_se_translator will still be
>but some C++ objects may not have destructors called, and the exception
>not be caught in the nearest enclosing scope. This isn't a problem
>_set_se_tranlator, per se, but due to the fact that the c++ compiler
>optimize-out exception handling frames where it can show that no
>can occur under the synchronous model.
That helps. So if you where to "throw" inside a translator, what happens
after that is not what you would think it should happen, that is, proper
stack unwinding at each nested level, but something more along the lines
of random behavior.
I wonder why VC does generate just a warning (level 4) about this and
not an error...
Reading David Abrahams' Guidelines at
Seems that a better execution_monitor will nicely complement them. That
is, if you subscribe to the camp that wants to avoid catch(...) whenever
possible then one should only catch specific kinds of exceptions and
whenever possible let execution_monitor handle the rest.
[mailto:boost-bounces_at_[hidden]] On Behalf Of Carl Daniel
Sent: Saturday, September 20, 2003 10:52 PM
Subject: [boost] Re: boost::execution_monitor impl under windows
carlos pizano wrote:
> Hello Boosters. I am looking into the boost.test library for insights.
> In particular I like the boost::execution_monitor idea. However, I
> that on Windows + VC execution_monitor implementation uses
> _set_se_translator() to translate native exceptions (SEHs) into C++
> exceptions, and I was fine with that for a while until I stumbled unto
> John Robbins book : "Debugging applications for Microsoft .NET and for
> Microsoft Windows" (Microsoft Press, 2003) chapter 13 specifically in
> pg. 524 he has section named "Don't Use _set_se_translator" where he
> goes to say that _set_se_translator:
> 1- Is not global, works only on a per thread basis
Naturally. Since DLLs frequently create internal worker threads, a
SE translator function would be very inappropriate.
> 2- Does not work in release builds (!!)
_set_se_translator works just fine in release builds.
> 3- Forces your code to use asynchronous exception handling (/EHa),
> which reduces performance and maybe increases code bloat.
This is true. If, that is, you're relying on proper C++ unwinding
when an SEH is raised. With /EHs, _set_se_translator will still be
but some C++ objects may not have destructors called, and the exception
not be caught in the nearest enclosing scope. This isn't a problem with
_set_se_tranlator, per se, but due to the fact that the c++ compiler may
optimize-out exception handling frames where it can show that no
can occur under the synchronous model.
Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk