1. "In both cases the destructor will be called. The first case is when the object is destroyed under normal circumstances, that is, when it leaves its living space or is explicitly deleted, and the second case is when the object is exception processing mechanism-that is, the stack-unwinding (stack expansion) mechanism in the exception propagation process-- Destroyed. ”
2. When destructor is called, it may (or may not) have a exception in effect, but we can no longer differentiate these states in destructor (there is now a differentiated approach.) July 1995 Ios/ansi C + + Standards Committee joins a new function: Uncaught_exception. If a exception is in action and has not been captured, it will return true). When destructor throws an exception and is not captured by destructor, it propagates to the destructor's caller, and if the destructor itself is invoked for one of his exception, The Terminate function is called, which by default calls the Abort function to terminate the program.
3. For 2 There is a workaround to prevent destructor thrown out of the exception out of destructor, that is, the destructor function body is wrapped in a try block, and catch (...) Statement does nothing, the sample code is as follows:
1 ~A () {2 try{3 ... 4 }5 catch(...) {}6}7//... Represents the middle of the code is omitted, ... Meta-operators on behalf of C + +
View Code
4. In addition to the reasons shown in 2, there is a downside to getting exception out of destructor: if destructor throws exception and is not captured locally, that destructor is incomplete, meaning it does not complete what it should.
5. In conclusion, there are two reasons to support us in taking measures to prevent exception from destructor: First, it avoids the terminate function being called in the stack expansion (stacking-unwinding) mechanism during exception propagation. Second, it can help ensure that destructors completes everything it needs to do.
More effective C + + clause 11 prohibits abnormal outflow of destructor