[boost] Re: [prereview request][fsm]

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
>>>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