[cfe-dev] The really scary part of noexcept
jonathan.sauer at gmx.de
Sun Mar 20 10:00:37 CDT 2011
> The above destructor would suddenly grow an exception-specification. Specifically, because it has no object data members, the exception-specification would be empty: it would be noexcept(true). If the conn.commit() call throws, the program would immediately terminate instead of letting the exception escape.
> Scary? Hell, yes! Useful? That too, when you consider that most constructors don't throw.
Don't you mean "destructors"? After all, that's what we're talking about.
> Now, the rationale for this part of the standard was that throwing destructors are high-risk parts of a program, so programmers would know where they are and check them when upgrading to C++0x. This argument makes sense - if you consider the C++0x transition global and instantaneous. But in reality, with compilers adopting different parts of the standard in different order, it's a headache.
> So my question is, how should we implement this in Clang? Simply put it under C++0x? Have it enabled in C++0x by default, but add a switch to turn it off? Add an explicit switch to turn it on?
The last option seems wrong, as it would mean that using only -std=c++0x would not result in standard-conformity. Adding a switch
to turn it off would be useful for backwards compatibility, but again would break standards compliance. So I would run with the first
option: The implicit "noexcept(true)" is part of the C++0x standard, therefore it should be enabled in C++0x by default.
I think a warning could be useful, though, which would trigger when a destructor does not have an *explicit* noexcept specifier. This
warning would then serve as a reminder to check the destructor(s) in question.
More information about the cfe-dev