"If a function isn't going to handle (or translate or deliberately absorb) an exception, it should allow the exception to propagate up to a caller who can handle it."
"Always structure your code so that resources are correctly freed and data is in a consistent state even in the presence of exceptions."
"Observe the canonical exception safety rules: Never allow an exception to escape from a destructor or from an overloaded operator delete() or operator delete[](); write every destructor and deallocation function as though it had an exception specification of "throw()"."
"Observe the canonical exception-safety rules: in each function, take all the code that right emit an exception and do all that work safely off to the side. Only then, when you know that the real work has succeeded, should you modify the program state (and clean up) using only nonthrowing operations."
"Prefer cohesion. Always endeavor to give each piece of code – each module, each class, each function – a single, well-defined responsibility."
"Always use the "resource acquisition is initialization" idiom to isolate resource ownership and management."
"Exception specifications can incur a performance overhead whether an exception is thrown or not, although many compilers are getting better at minimizing this. For widely-used operations and general-purpose containers, it may be better not to use exception specifications in order to avoid this overh"
"All destructors should always be implemented as though they had an exception specification of throw() -- that is, no exception must ever be allowed to propagate."