From: Robert Bell (belvis_at_[hidden])
Date: 2004-06-01 13:36:18
Rob Stewart wrote:
> From: "E. Gladyshev" <eegg_at_[hidden]>
>>From: "Rob Stewart" <stewart_at_[hidden]>
>>>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
>>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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk