c++ - Are the copy constructor and copy assignment of std::runtime_error noexcept? -

all of gcc 4.8.4, 4.9.3, 5.3.0 pass tests std::exception (for of -std=c++11/1y/14/1z/17 options, available):

static_assert(std::is_nothrow_copy_constructible<std::exception>::value, "test exception"); static_assert(std::is_nothrow_copy_assignable   <std::exception>::value, "test exception"); 

which fine, since std::exception has noexcept special members (c++14 18.8.1):

namespace std {   class exception {   public:     exception() noexcept;     exception(const exception&) noexcept;     exception& operator=(const exception&) noexcept;     virtual ~exception();     virtual const char* what() const noexcept;   }; } 

unfortunately, of compilers above fail on following static_asserts:

static_assert(std::is_nothrow_copy_constructible<std::runtime_error>::value, "test runtime_error"); static_assert(std::is_nothrow_copy_assignable   <std::runtime_error>::value, "test runtime_error"); 

the standard contains following std::runtime_error in 19.2.6:

namespace std {   class runtime_error : public exception {   public:     explicit runtime_error(const string& what_arg);     explicit runtime_error(const char* what_arg);   }; } 

but nothing said noexceptness of other (implicitly declared special) members nor storage implementation requirements of what_arg.

the standard (c++14) says following in 15.4/14:

an inheriting constructor (12.9) , implicitly declared special member function (clause 12) have exception-specification. if f inheriting constructor or implicitly declared default constructor, copy constructor, move constructor, destructor, copy assignment operator, or move assignment operator, implicit exception-specification specifies type-id t if , if t allowed exception-specification of function directly invoked f’s implicit definition; f allows exceptions if function directly invokes allows exceptions, , f has exception-specification noexcept(true) if every function directly invokes allows no exceptions.

and following in 18.8.1/2:

each standard library class t derives class exception shall have publicly accessible copy constructor , publicly accessible copy assignment operator not exit exception.

since std::runtime_error not expose implementation of what_arg storage, not know whether it's (special) members noexcept or not, noexceptness of std::runtime_error's copy constructor or copy assignment members undecidable. our bet 18.8.1 above.

question 1/a) consider std::runtime_error's copy constructor or copy assignment noexcept (1, 2). true / state-of-the-art / best practice?

question 1/b) not need explicitly state in standard? (like in 18.8.2, class bad_exception)

question 1/c) bug in gcc fails static_assert tests above?

question 2) if above deduction wrong, point me section(s) in standard state std::runtime_error has noexcept copy constructor (and copy assignment)? (or states not.)

consider lwg 1371:

none of exception types defined in clause 19 allowed throw exception on copy or move operations, there no clear specification operations have exception specification prove it. note implicitly declared constructors, taking exception specification base class (ultimately std::exception) implicitly generate noexcept exception specification if of data members declare noexcept operations. representation unspecified, cannot assume nonthrowing operations unless explicitly state constraint on implementation.

[ resolution proposed ballot comment: ]

add global guarantee exception types defined in clause 19 rely on implicitly declared operations have non-throwing exception specification on operations.

in 2010 batavia meeting, found [exception]/2 "covered this":

each standard library class t derives class exception shall have publicly accessible copy constructor , publicly accessible copy assignment operator not exit exception.

therefore still isn't mandated these special member functions noexcept. , according way implicit exception specifications determined in [except.spec]/16, since implementation can add both arbitrary parameters default arguments , members, it's implementation-specific whether or not these special member functions noexcept.

---