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

From: E. Gladyshev (eegg_at_[hidden])
Date: 2004-06-01 10:54:15

----- Original Message ----- 
From: "Rob Stewart" <stewart_at_[hidden]>

[...]

> 
> The point is that the library client that is bothered by
> boost::fsm triggering stack unwinding probably has a means of
> dealing with the exceptions that would otherwise undesirably
> cause stack unwinding.
> 

In real life, it is a very tough requirement to meet...
and it'll make you code not portable.

The bottom line is that catch(...) doesn't allow you 
to make the following important design decision:
- All exceptions have to be derived from E.
- All other exceptions are caused by a bug and 
should not trigger stack unwinding.

[...]
> > Sorry, who said that stack unwinding is faulty?
> 
> You said "it is not safe to trigger stack unwinding in a buggy
> environment."  

It is not the same as "stack unwinding is faulty", is it?

[...]
> 
> 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
*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.

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.

Anyway, I think that this issue isn't directly related to fsm.
There was an extensive discussion about this stuff 
at c++.moderated. You might want to take a look at it.

Eugene