From: "Rob Stewart" <stewart@sig.com>
From: "E. Gladyshev" <eegg@comcast.net>
From: "Rob Stewart" <stewart@sig.com>
[...]
So, OK, there is that slight difference, but why would you care?
I don't think that it is a slight difference. If you make an assumption that all unhandled exceptions will eventually trigger stack unwinding, but a specific implementation doesn't do that, it is huge difference.
Why would you want the non-deterministic behavior?
Whether I want it or not doesn't change anything. All I am saying that it is implementation dependent and it is a big difference. [...]
Why would you want terminate() to be called without stack unwinding on those platforms that do it? What does that get you? I would think that boost::fsm's behavior, being more deterministic, would be preferable.
There could be many reasons, just to list few of them. 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. 2. Your design assumes that all possible exceptions are known and you handle them. So any unhandled exception is a bug. It is not safe to trigger stack unwinding in a buggy environment. These reasons could be of a particular importance in control applications where state machines are a must. But again whether I want it or not, the Standard allows implementation where the stack unwinding (for unhandled exceptions) never happens. [...]
Does not unwinding the stack when terminate() is called, on whatever platforms do that, gain you something that outweighs the determinism and reuse of the boost::fsm approach?
Please see above. Eugene