Boost logo

Boost :

From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-10-01 13:33:25

Alan.Griffiths_at_[hidden] wrote:
> > Raising SEH exception (or signal) is clearly a *side effect* (that
> > isn't "covered" by the C/C++ standard...
> If it isn't covered by the standard then the rules in the standard do not
> cover it.

I guess it would really help you (to kinda "see the forest for the
trees") if throw-expressions and std::raise() would be formally
listed as side effects. Oder? ;-) The rest simply follows... as I
said, SEH exceptions are just ought to be "fully mapped" to the
standard C++ exceptions.

> o by the runtime environment (which calls "unexpected"
> without *any* cleanup). While the program as a whole
> is clearly broken in this case, this breaks cleanup
> guarantees that exist between the throw point and the
> top of the stack.

ISO/IEC 14882:

"If no matching handler is found in a program, the function
 terminate() is called; whether or not the stack is unwound
 before this call to terminate() is implementation-defined"

> I prefer the existing behaviour.

Ronald Reagan:

"Status quo, you know, that is Latin for ``the mess we're in.''"

> In short, I don't understand what you are trying to achieve - and whatever
> that might be you are introducing new problems for the developer.
> Am I missing something blindingly obvious?

David Butenhof:

"I suspect it's one of those things that's too subtle to see until
 you've got experience with the alternatives; and probably nobody
 had really perceived the power of a good 2-phase exception system
 that's used correctly. ;-)"


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