From: "E. Gladyshev" <eegg@comcast.net>
--- Rob Stewart <stewart@sig.com> wrote:
From: "E. Gladyshev" <eegg@comcast.net>
try{...} catch(...) { try { throw; } catch( type1 ) { ... } }
is very different from
try{...} catch( type1 ) {...}
[...]
IOW, stack unwinding will occur for both forms, it's just a question as to where the handler will be found.
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: 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). So, OK, there is that slight difference, but why would you care? Why would this -- no stack unwinding for an unhandled exception -- matter in boost::fsm? Put another way, what benefit does this provide and does it outweight the benefits of the approach being used now? -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;