----- Original Message ----- From: "Rob Stewart" <stewart@sig.com>
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:
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).
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. Such an implementation (legal implementation, btw) may break a bunch of RAII based designs.
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.
Put another way, what benefit does this provide and does it outweight the benefits of the approach being used now?
Sorry, what outweighs what? Eugene