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

From: Rob Stewart (stewart_at_[hidden])
Date: 2004-06-01 08:59:59

From: eegg_at_[hidden]
> --- Rob Stewart <stewart_at_[hidden]> wrote:
> > From: "E. Gladyshev" <eegg_at_[hidden]>
> > > From: "Rob Stewart" <stewart_at_[hidden]>
> > > > From: "E. Gladyshev" <eegg_at_[hidden]>
> > > > > From: "Rob Stewart" <stewart_at_[hidden]>
> 
> > > 1. Some platforms pose non-C++ exceptions as normal C++ exception.
> > >     You don't always want those platfrom specific exceptions trigger
> > >     a whole bunch of stuff in your program.
> > 
> > The only platform I know of that does that is Windows/MSVC
> 
> It makes it pretty common, doesn't it. :)

Sad, but true.  (Well, the Windows part, I mean.  MSVC 7.1 is
quite good, I understand.)

> > you can handle structured exceptions specially.  Perhaps it
> > means that boost::fsm needs to provide a means to install an
> > exception handler for those exceptions not already recognized by
> > the library:
> > 
> > try { throw; }
> > catch (...) { boost::fsm::detail::handle_exception(); }
> > 
> > void boost::fsm::detail::handle_exception()
> > {
> >    try { throw; }
> >    catch (type1 const &) { ... };
> >    catch (type2 const &) { ... };
> >    catch (type3 const &) { ... };
> >    catch (...) { user_handler(); }
> > }
> > where user_handler is a pointer to function that's initialized to
> > std::unexpected() and can be overridden by the library user.
> 
> Adding user_handler() doesn't stop stack unwinding.
> I think you are missing the point.
> The issue is not in how to process SEH exceptions
> (or any other unhandled exception) the issue is in
> how not to trigger stack unwinding (for all exceptions)
> and still be able discriminate user exception 
> types generically in FSM.
> Your solution doesn't solve this problem.

You stated that, but no one had proffered a good reason for
wanting to avoid stack unwinding by the time I wrote that.  You
mentioned non-C++ exceptions infiltrating via catch (...), so I
was discussing techniques whereby a concerned library user might
be able to keep SEH from interfering with the proposed EH in
boost::fsm.

> > It may also be that SEH can be configured to intervene before a
> > C++ exception is generated by the RTL so those never become C++
> > exceptions that can muck up the works.
> 
> It is not trivial... but it is out of the FSM topic.

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.

> > > 2. Your design assumes that all possible exceptions are known
> > >     and you handle them. So any unhandled exception is a bug.
> > 
> > Not quite.  What I was showing would rethrow any unknown
> > exception, leaving to clients to determine how to handle it.
> > 
> > >     It is not safe to trigger stack unwinding in a buggy environment.
> > 
> > If you say so.  Every application and platform with which I work
> > is buggy and yet I manage to use exceptions and stack unwinding
> > works.  
> 
> What do you mean by "stack unwinding works". Do you mean
> that even if the exception is caused by a bug,
> stack unwinding didn't make things worse or less safer?
> Well, it's a long shot...
> 
> [...]
> > This is just another case of things not being as pretty
> > as one might like but that doesn't mean stack unwinding is
> > faulty.
> 
> Sorry, who said that stack unwinding is faulty?

You said "it is not safe to trigger stack unwinding in a buggy
environment."  I'm saying that despite bugs in compilers and
applications, one can still take advantage of stack unwinding.
Sure, things can -- and do -- go wrong and you sometimes track
those back to compiler bugs.  Nevertheless, you use the
facilities you have.

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?

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