Rob Stewart wrote:
From: "E. Gladyshev" <eegg@comcast.net>
From: "Rob Stewart" <stewart@sig.com>
What I understand you to say is that there is some error indicated by SEH that will be caught by catch (...) and that will trigger stack unwinding and it is unwise to permit stack unwinding at that point. Is that really any different than stack unwinding because of an out of range index or insufficient memory?
Yes, it is very different! The "out of range" or "insufficient memory exceptions" don't happen on their own. You have to throw them
Sure they do: if you call new, you get std::bad_alloc. It is the RTL that throws the exception. Granted, the exception occurs at a well defined time and the same can't be said for structured exceptions, right?
*explicitly. So before throwing them, you can make sure that the broken invariant (if any) is restored . If the invariant is restored, stack unwinding is safe.
What about exceptions thrown to indicate a violated invariant?
Throwing exceptions to indicate a violated invariant is a pretty bad idea; it means you've left part of your system with broken invariants; i.e. you can't depend on that part of the system for anything.
That is, the basic guarrantee?
The basic guarantee means no invariants are violated.
IOW, if an invariant is violated, the object can be left in a destructible state, but nothing more can be said for its use.
If part of the invariants of an object are that it may be placed into a destructible state, but nothing else works, then its invariants really aren't violated, aren't they?
SEH's on the other hand can happen at "any place" in your program (even when the invariant is broken). If the invariant is broken, stack unwinding is not safe.
Then you can't write code with the basic guarrantee can you?
Not with asynchronous SEH's flying around. SEH's are a problem, aren't they? Bob