I’ve already shown a case where exceptions being propagated from destructors is problematic, there are other problems. For example, e.g. during stack unwinding an exception can lead via std::unexpected() to std::terminate() and the program aborting. There is no pressing reason to allow exceptions to propagate from a destructor, and it severely limits what use can be made of the object concerned. Don’t do it!
The second rule isn’t obvious, but is part of the key to exception safety. Even if a class owns resources, exchanging the states of two instances should be possible without allocating (temporary) resources or throwing an exception (if the allocation fails). For example the STL containers provide this facility by overloading std::swap(). We’ll see how useful the ability to swap states is in a moment.
The third rule addresses the cause of all the messy exception handling code we’ve just seen. It was the fact that creating second part might fail by throwing an exception that doubled the number of lines in the assignment operator.
