<div dir="ltr"><div><div>-fno-exceptions causes EH constructs such as try/catch, function-try-blocks, and throw expressions to be diagnosed with a severe error. That is, -f[no-]exceptions controls a language-support property.<br><br></div>For experiments in evaluating the cost of (unused) exception handling, and for cases where components are being deployed with the expectation that exceptions will not be thrown, etc. it is useful to allow EH constructs in the source, but to generate code with no handlers or cleanups.<br><br></div><div>I think that it still makes sense under such a mode to allow throw expressions to throw. This is consistent with -fno-exceptions still calling __cxa_bad_cast and __cxa_bad_typeid (which GCC also does, but not with __cxa_throw_bad_array_new_length).<br><br></div><div>That is, the proposed semantics is essentially the same as for -fno-exceptions, except to treat try/catch and function-try-blocks as just normal code introducing no handlers, and to allow throw expressions.<br><br></div><div>-fno-exceptions already suppresses creation of cleanups for unwinding and the ignoring of exception specifications.<br><br></div><div>I like to think of this as -fignore-exceptions. I have a use for this, and I would like to know what people think.<br><br></div><div>-- HT<br><br></div></div>