From: "E. Gladyshev" <eegg@comcast.net>
From: "Rob Stewart" <stewart@sig.com>
15.5.1/2 Note: in the situation where no matching handler is found, it is implementation-defined whether
or
not the stack is unwound before terminate() is called. In all
other
situations, the stack shall not be unwound before terminate()
is
called
Your claim that the stack unwinding will occur in both cases is based on an implementation-defined behavior. In fact, all implementations that I know about allows you disable the stack unwinding for unhandled exceptions. So it is not strictly portable nor generic.
That's non-normative text, but it turns out that 15.3/9 covers it:
I don't understant what you mean by "15.3/9 covers it"?
If no matching handler is found in a program, the function terminate() is called; whether or not the stack is unwound before this call to terminate() is implementationdefined (15.5.1).
15.3/9 is normative text and, as quoted here, clearly states that stack unwinding may not be done before calling terminate().
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?
Such an implementation (legal implementation, btw) may break a bunch of RAII based designs.
Well, that may be a problem in the specification of the language that should be addressed. After all, RAII is generally the preferred solution for writing exception tolerant code. Perhaps Dave Abrahams can weigh in on this.
Why would this -- no stack unwinding for an unhandled exception -- matter in boost::fsm?
Because boost::fsm doesn't allow me to discriminate exception types and keep the stack from unwinding (for unhandled exceptions) at the same time.
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.
Put another way, what benefit does this provide and does it outweight the benefits of the approach being ^^^^^^^^^ Man I've got to stop my brain from adding that extra "t!"
used now?
Sorry, what outweighs what?
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? -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;