From: Alexander Terekhov (terekhov_at_[hidden])
Date: 2003-10-01 13:33:25
> > 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.
"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.
"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?
"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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk