From: eegg@comcast.net
--- Rob Stewart <stewart@sig.com> wrote:
From: "E. Gladyshev" <eegg@comcast.net>
From: "Rob Stewart" <stewart@sig.com>
From: "E. Gladyshev" <eegg@comcast.net>
From: "Rob Stewart" <stewart@sig.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. :)
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@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;