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

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-06-01 12:00:40

From: "E. Gladyshev" <eegg_at_[hidden]>
> 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 preprocessor can handle that for those platforms where you
have to worry about SEH, right?

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

Based upon Dave A mentioning that unhandled exceptions might lead
to a core dump, I can see that no stack unwinding could be
useful.  The alternative is to rerun the application under a
debugger, attempt to recreate the conditions leading up to the
exception, and then inspect the call stack just as the exception
is about to be thrown (depending upon the capabilities of your
debugger, of course).

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

I guess I meant using it was a faulty enterprise.  The point was
that you were saying if things are buggy, don't make use of stack
unwinding.  I think I now see that you meant permitting
exceptions to propagate unhandled prevents stack unwinding and
leads to a core dump which makes tracking down the bug easier.

> > 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?
That is, the basic guarrantee?  IOW, if an invariant is violated,
the object can be left in a destructible state, but nothing more
can be said for its use.

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

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

I'll try to do that.  Thanks.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;