“noexcept” vs “Throws: nothing” [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers. Learn more.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

While going through the last edits of the C++0x Working draft I found a lot of

• removal of the keyword noexcept
• addition of textual Throws: nothing at the same place

and vice versa. Just some examples:

• replacement of noexcept against Throws: nothing: 20.6.4 Pointer safety [util.dynamic.safety] template<class T> T*undeclare_reachable(T*p);
• addition of noexcept: 20.6.3.2. Pointer traits member functions [pointer.traits.functions]: static pointer pointer_trait<T*>::pointer_to(...) noexcept;

Questions here:

• Is there a general rule/pattern, when we will find noexcept vs. Throws: nothing in the Std-Lib?
• Should users derive a specific behavior by that given rule? I.e. when they should or should not add noexcept to their own functions?

Answer 1

In Madrid we were strongly influenced by N3279 which includes the following guidelines:

Adopted Guidelines

• No library destructor should throw. They shall use the implicitly supplied (non- throwing) exception specification.

• Each library function having a wide contract, that the LWG agree cannot throw, should be marked as unconditionally noexcept.

• If a library swap function, move-constructor, or move-assignment operator is conditionally-wide (i.e. can be proven to not throw by applying the noexcept operator) then it should be marked as conditionally noexcept. No other function should use a conditional noexcept specification.

• Library functions designed for compatibility with “C” code (such as the atomics facility), may be marked as unconditionally noexcept.

I would not interpret these guidelines as necessarily targeting a wider audience. This is mainly an admission that we do have backward compatibility concerns with adding noexcept. If we get it wrong, noexcept is easier to add than to remove in the next standard. So we attempted an application of noexcept that was both conservative and systematic.