Boost logo

Boost :

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-10-08 12:34:00

David Abrahams wrote:
> I asked David Butenhof to explain the issue since I couldn't get any
> other explanation. We had a long discussion about it. Basically, the
> conclusion I (we) came to was that 2-phase EH is a good QOI choice as
> a workaround for platforms where exception throwing due to
> "asynchronous" interrups like crashes and signals has been instituted,
> but that mandating it in the standard would be a mistake, because it
> provides very few advantages on other platforms, and there is no
> advantage to that kind of crash=exception throwing in the first place.

How many times do I need to repeat that the issue here is unneeded
and *hurting* unwinding for ANY unexpected exception -- "normal" C++
"throw-expressions" including. I have THE APPLICATION that doesn't
handle std::bad_alloc because it documents its address space size
requirements and all std::bad_alloc's are either "admin errors" or
indications of some serious flaw (leaking, corruption, whatever). I
neither *really want* nor *really can* wrap all "operator new(size_t)
and "operator new[](size_t)" calls with catch(const std::bad_alloc&)
{ abort(); } (or replace them with std::nothrow_t stuff and "if").

> The sorts of advantages that apply everywhere are relegated to
> debugging relatively obscure conditions, e.g., that it may be easier
> to debug an exception-specification violation that the runtime can
> detect will be violated at the throw point, since the program can core
> dump

and, more importantly, failover...

> immediately.

Right. Some optimizations would be possible too.

> But not all ES violations can be detected that way.

Really? Such as? Please elaborate.

> One thing we decided might be useful is a way to label _certain_
> cleanups, such as those that delete files used as inter-process
> mutexes, as "should happen on termination, even if no unwinding
> occurs". ....
(If you insist on emergency cleanup...)


Boost list run by bdawes at, gregod at, cpdaniel at, john at