I apologize for post this again. It is a copy of my previous post
that somehow ended up in the wrong branch.

Eugene


--- Rob Stewart <stewart@[...].com>  wrote:
>  From: "E. Gladyshev" <eegg@[...].net>
>  > From: "Rob Stewart" <stewart@[...].com>
>  > > From: "E. Gladyshev" <eegg@[...].net>
>  > > > From: "Rob Stewart" <stewart@[...].com>
>  > 

[...]

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

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

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

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

Eugene


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost