New rule proposal: exception types should be nothrow copyable

[szaszm]

There is a similar rule in the SEI CERT C++ Coding Standard: ERR60-CPP. Exception objects must be nothrow copy constructible (down at the time of submitting this issue).

Rationale: exception objects are copy-initialized, and if an implementation chooses to not elide this copy, or there is an additional copy at the catch site (i.e. not following E.15: Throw by value, catch exceptions from a hierarchy by reference), and the copy constructor throws, then std::terminate is called.

It's sufficient if the exception type is nothrow copy constructible, but I can't see why someone would want to make a throwing copy assignment operator at the same time, aside from doing some magic in the copy constructor and not bothering to define a copy assignment operator, but that already violates the rule of three / five.

[N-Dekker]

Would such a rule suggest using reference counting, internally, when the exception object contains dynamically allocated memory?

It's quite common for a user-defined exception class to have a dynamically allocated string, holding an error message.

[szaszm]

Yes, a std::shared_ptr<const char[]> or a std::shared_ptr<const std::string> inside the exception object is one way of achieving this. I usually just derive from one of the standard exception types that already contains a message, and use its storage.
e.g.:

struct my_exception : std::runtime_error {
  using std::runtime_error::runtime_error;
};

[hsutter]

Editors call: We think this is a good suggestion. We plan to extend E.16 to include exception type copy/move construction.

[N-Dekker]

@hsutter Thank you for addressing this issue, cool! Small nitpick, it now says at

CppCoreGuidelines/CppCoreGuidelines.md

Line 16137 in d5907d6

- Try not to `throw` a type whose copy constructor is not `noexcept`. In general we cannot mechanically enforce this, because even `throw std::string(...)` could throw but does not in practice.

even throw std::string(...) could throw but does not in practice.

Sounds a bit interesting. Of course, throw does throw!

I guess you mean something like:

even when throwing an std::string, its copy-constructor could throw, but that is highly unlikely to happen in practice

Right? Would you like to fix it directly on the master branch, or would you rather have a pull request?