Under certain circumstances, terminating a function by throwing an exception will can trigger undefined behavior.
For instance, the C++ Standard, [basic.stc.dynamic.deallocation], paragraph 3 [ISO/IEC 14882-2014], states in part:
...
As such, deallocation functions (object, array, and placement forms at either global or class scope) must not be declared noexcept(false) but may instead rely on the implicit noexcept(true) or declare noexcept explicitly.
In other circumstances, terminating a function by throwing an exception has a strong potential to trigger undefined behavior. For instance, destructors Object destructors are likely to be called during stack unwinding as a result of an exception being thrown. If the destructor itself throws an exception, having been called as the result of an exception being thrown, then the function std::terminate() is called with the default effect of calling std::abort() [ISO/IEC 14882-2014]. When std::abort() is called, no further objects are destroyed, resulting in indeterminate program state and undefined behavior.
...
An implicit declaration of a destructor is considered to be noexcept(true) according to [except.spec], paragraph 14. As such, destructors must not be declared noexcept(false) but may instead rely on the implicit noexcept(true) or declare noexcept explicitly.
Note , any function declared noexcept that terminates by throwing an exception does not conform to that any noexcept function that throws an exception violates ERR55-CPP. Honor exception specifications.
...