Effective C + + reading notes clause 08

Article 08 do not let an exception escape the destructor:

If an exception occurs in a destructor, the program may end prematurely or cause ambiguous behavior (exceptions propagate from the destructor)

Look at the code:

#include <iostream>using namespace Std;class dbconnection{public:void Close () {int i = 3;int j = 0;int k = i/j;printf ("%d\n", k);}; Class Dbconn{public:dbconn () {}/*~dbconn () {db.close ();} *///Solution 1: Forced End Program ~dbconn () {try{db.close ();} catch (...) {abort ();//If a program cannot continue to allow after encountering an "error during destruction", forcing the end is a reasonable choice. Use abort to prevent exceptions from being propagated out of the destructor}}//Solution 2: Swallow exception/*~dbconn () {try{db.close ();} catch (...) {//Make a running record, note that the call to close failed}} */private:dbconnection DB;}; The close function of the dbconnection is automatically called when the int main () {Dbconn Dbc;//dbc object is destroyed, as long as the call to close succeeds, but if an exception is encountered in the call, the Dbconn destructor//propagates the exception. That is, allowing it to leave this destructor. can cause problems. return 0;} /* Use the original destructor: Run the program, prompting that a program has stopped working (it feels like the compiler is optimized to solution 1, automatic Processing), and if it does not stop working, there are also ambiguous behavior. With solution 1: Run the program, prompting for a debug error to terminate the program. With Solution 2: Run the program, the program runs through, but it does not print the value of K */

The above solutions, 1 and 2, cause exceptions that are thrown on close to be unhandled:

The best way to do this is to dbconn yourself by re-designing a close interface so that programmers can invoke it themselves:

#include <iostream>using namespace Std;class dbconnection{public:void Close () {int i = 3;int j = 0;int k = i/j;printf ("%d\n", k);}; Class Dbconn{public:dbconn () {}~dbconn () {if (!closed) {try  //close connection if the client does not do so {db.close ()}catch (...) {//End the program here or swallow the exception}}} void Close () {db.close (); closed = true;} Private:dbconnection db;bool closed;}; The close function of the dbconnection is automatically called when the int main () {Dbconn Dbc;//dbc object is destroyed, as long as the call to close succeeds, but if an exception is encountered in the call, the Dbconn destructor//propagates the exception. That is, allowing it to leave this destructor. can cause problems. return 0;} /* This method moves the responsibility of calling close from the Dbconn destructor to the Dbconn client hand (but the Dbconn destructor still contains a "double insurance" called). If an operation may throw an exception on failure, and there is a need to handle the exception, then the exception must come from a function other than the destructor because the destructor spits out the exception, it always brings the risk of "prematurely ending the program" or "ambiguous behavior." The close function is called by the client itself and can be handled if an exception is found. Summary:  1: Destructors never spit out an exception, if a function called by a destructor might throw an exception, the destructor should catch the exception and swallow it (not propagate) or end program  2: If the customer needs to react to an exception thrown during the operation of an action function, Then class should provide a normal function (not a destructor) to perform the operation. */

1: destructor never spits out an exception, if a function called by a destructor might throw an exception, the destructor should catch the exception and swallow it (not propagate) or end the program

2: If the customer needs to react to an exception that is thrown during the operation of an action function, then class should provide a normal function (not a destructor) to perform the operation.

Effective C + + reading notes clause 08