...
Consequently, the caught exception will inevitably escape from the SomeClass destructor because it is implicitly rethrown when control reaches the end of the function-try-block handler/.
Compliant Solution
A destructor should perform the same way whether or not there is an active exception. Typically, this means that it should invoke only operations that do not throw exceptions, or it should handle all exceptions and not rethrow them (even implicitly). This compliant solution differs from the previous noncompliant code example by having an explicit return statement in the SomeClass destructor. This statement prevents control from reaching the end of the exception handler. Consequently, this handler will catch the exception thrown by Bad::~Bad() when bad_member is destroyed. It will also catch any exceptions thrown within the compound statement of the function-try-block, but the SomeClass destructor will not terminate by throwing an exception.
...
| [Henricson 97] | Recommendation 12.5, Do not let destructors called during stack unwinding throw exceptions |
| [ISO/IEC 14882-2014] | Subclause 3.4.7.2, "Deallocation Functions" |
| [Meyers 052005] | Item 8, "Prevent Exceptions from Leaving Destructors" |
| [Sutter 002000] | "Never allow exceptions from escaping destructors or from an overloaded operator delete()" (p. 29) |
...