// Exceptions clean up complete objects only
#include <iostream>
using namespace std;
class Trace {
static int counter;
int objid;
public:
Trace() {
objid = counter++;
cout << "constructing Trace #" << objid << endl;
if(objid == 3) throw 3;
}
~Trace() {
cout << "destructing Trace #" << objid << endl;
}
};
int Trace::counter = 0;
int main() {
try {
Trace n1;
// Throws exception:
Trace array[5];
Trace n2; // won't get here
} catch(int i) {
cout << "caught " << i << endl;
}
} ///:~
The class Trace keeps track of objects so that you can trace program progress. It keeps a count of the number of objects created with a static data member counter and tracks the number of the particular object with objid.
The main program creates a single object, n1 (objid 0), and then attempts to create an array of five Trace objects, but an exception is thrown before the third object is fully created. The object n2 is never created. You can see the results in the output of the program:.
constructing Trace #0
constructing Trace #1
constructing Trace #2
constructing Trace #3
destructing Trace #2
destructing Trace #1
destructing Trace #0
caught 3
Three array elements are successfully created, but in the middle of the constructor for the fourth element, an exception is thrown. Because the fourth construction in main( ) (for array[2]) never completes, only the destructors for objects array[1] and array[0] are called. Finally, object n1 is destroyed, but not object n2, because it was never created.
Resource management
When writing code with exceptions, it’s particularly important that you always ask, "If an exception occurs, will my resources be properly cleaned up?" Most of the time you’re fairly safe, but in constructors there’s a particular problem: if an exception is thrown before a constructor is completed, the associated destructor will not be called for that object. Thus, you must be especially diligent while writing your constructor.
The general difficulty is allocating resources in constructors. If an exception occurs in the constructor, the destructor doesn’t get a chance to deallocate the resource. This problem occurs most often with "naked" pointers. For example:.
//: C01:Rawp.cpp
// Naked pointers
#include <iostream>
using namespace std;
class Cat {
public:
Cat() { cout << "Cat()" << endl; }
~Cat() { cout << "~Cat()" << endl; }
};
class Dog {
public:
void* operator new(size_t sz) {
cout << "allocating a Dog" << endl;
throw 47;
}
void operator delete(void* p) {
cout << "deallocating a Dog" << endl;
::operator delete(p);
}
};
class UseResources {
Cat* bp;
Dog* op;
public:
UseResources(int count = 1) {
cout << "UseResources()" << endl;
bp = new Cat[count];
op = new Dog;
}
~UseResources() {
cout << "~UseResources()" << endl;
delete [] bp; // Array delete
delete op;
}
};
int main() {
try {
UseResources ur(3);
} catch(int) {
cout << "inside handler" << endl;
}
} ///:~
The output is the following:.
UseResources()
Cat()
Cat()
Cat()
allocating a Dog
inside handler
The UseResources constructor is entered, and the Cat constructor is successfully completed for the three array objects. However, inside Dog::operator new( ), an exception is thrown (to simulate an out-of-memory error). Suddenly, you end up inside the handler, without the UseResources destructor being called. This is correct because the UseResources constructor was unable to finish, but it also means the Cat objects that were successfully created on the heap were never destroyed.
Making everything an object
To prevent such resource leaks, you must guard against these "raw" resource allocations in one of two ways:
· You can catch exceptions inside the constructor and then release the resource.
· You can place the allocations inside an object’s constructor, and you can place the deallocations inside an object’s destructor.
Using the latter approach, each allocation becomes atomic, by virtue of being part of the lifetime of a local object, and if it fails, the other resource allocation objects are properly cleaned up during stack unwinding. This technique is called Resource Acquisition Is Initialization (RAII for short) , because it equates resource control with object lifetime. Using templates is an excellent way to modify the previous example to achieve this:.
//: C01:Wrapped.cpp
// Safe, atomic pointers
#include <iostream>
using namespace std;
// Simplified. Yours may have other arguments.
template<class T, int sz = 1> class PWrap {
T* ptr;
public:
class RangeError {}; // Exception class
PWrap() {
ptr = new T[sz];
cout << "PWrap constructor" << endl;
}
~PWrap() {
delete [] ptr;
cout << "PWrap destructor" << endl;
}
T& operator[](int i) throw(RangeError) {
if(i >= 0 && i < sz) return ptr[i];
throw RangeError();
}
};
class Cat {
public:
Cat() { cout << "Cat()" << endl; }
~Cat() { cout << "~Cat()" << endl; }
void g() {}
};