If a function can throw an exception for whatever reason, even if it is std::bad_alloc
, you should not declared it as noexcept
. There are relatively few functions which really can't throw an exception and where it actually also matters. The primary need for noexcept
functions is to allow the detection of the available error recovery options in case of an exception: For example, std::vector<T, A>
can use move construction when inserting an object assuming that move construction doesn't throw. If move construction can throw, moving objects cannot be used to recover for an exception when implementing strong exception safe operations. Thus, if move construction can fail for the type T
an instantiation of std::vector<T, A>
cannot move objects but needs to copy them.
In particular, do not use noexcept
as false documentation: it is a breach of contract if the function actually can throw. The fact that the system reacts with some level of defined behavior in case of this breach doesn't mean that you should take advantage of it. ... and while simple programs probably won't recover and just die when running out of memory, real programs may at least need to store sufficient state to recover the mess they leave behind when dieing, i.e., it is not acceptable for any function to make a decision about killing the program (unless, of course, this is documented intend of the function).