Since the only error you anticipate is a stack underflow, you might think it’s safe to specify a logic_error or some other appropriate exception type. But since you don’t know much about the type T, what if its copy constructor could possibly throw an exception (it’s not unreasonable, after all)? Then unexpected( ) would be called, and your program would terminate. The point is that you shouldn’t make guarantees that you can’t stand behind. If you don’t know what exceptions might occur, don’t use exception specifications. That’s why template classes, which constitute 90 percent of the Standard C++ library, do not use exception specifications—they specify the exceptions they know about in documentation and leave the rest to you. Exception specifications are mainly for non-template classes.
Exception safety
In Chapter 7 we’ll take an in-depth look at the containers in the Standard C++ library, including the stack container. One thing you’ll notice is that the declaration of the pop( ) member function looks like this:
void pop();
You might think it strange that pop( ) doesn’t return a value. Instead, it just removes the element at the top of the stack. To retrieve the top value, call top( ) before you call pop( ). There is an important reason for this behavior, and it has to do with exception safety, a crucial consideration in library design.
Suppose you are implementing a stack with a dynamic array (we’ll call it data and the counter integer count), and you try to write pop( ) so that it returns a value. The code for such a pop( ) might look something like this:
template<class T>
T stack<T>::pop() {
if (count == 0)
throw logic_error("stack underflow");
else
return data[--count];
}
What happens if the copy constructor that is called for the return value in the last line throws an exception when the value is returned? The popped element is not returned because of the exception, and yet count has already been decremented, so the top element you wanted is lost forever! The problem is that this function attempts to do two things at once: (1) return a value, and (2) change the state of the stack. It is better to separate these two actions into two separate member functions, which is exactly what the standard stack class does. (In other words, follow the time-worn design practice of cohesion—every function should do one thing well.) Exception-safe code leaves objects in a consistent state and does not leak resources.
You also need to be careful writing custom assignment operators. In Chapter 12 of Volume 1, you saw that operator= should adhere to the following pattern:
1. Make sure you’re not assigning to self. If you are, go to step 6. (This is strictly an optimization.)
2. Allocate new memory required by pointer data members.
3. Copy data from the old memory to the new.
4. Delete the old memory.
5. Update the object’s state by assigning the new heap pointers to the pointer data members.
6. Return *this.
It’s important to not change the state of your object until all the new pieces have been safely allocated and initialized. A good technique is to move all of steps 2 and 3 into a separate function, often called clone( ). The following example does this for a class that has two pointer members, theString and theInts.
//: C01:SafeAssign.cpp
// Shows an Exception-safe operator=
#include <iostream>
#include <new> // For std::bad_alloc
#include <cstring>
using namespace std;
// A class that has two pointer members using the heap
class HasPointers {
// A Handle class to hold the data
struct MyData {
const char* theString;
const int* theInts;
size_t numInts;
MyData(const char* pString, const int* pInts,
size_t nInts)
: theString(pString), theInts(pInts),
numInts(nInts) {}
} *theData; // The handle
// clone and cleanup functions
static MyData* clone(const char* otherString,
const int* otherInts, size_t nInts){
char* newChars = new char[strlen(otherString)+1];
int* newInts;
try {
newInts = new int[nInts];
} catch (bad_alloc&) {
delete [] newChars;
throw;
}
try {
// This example uses built-in types, so it won't
// throw, but for class types it could throw, so we
// use a try block for illustration. (This is the
// point of the example!)
strcpy(newChars, otherString);
for (size_t i = 0; i < nInts; ++i)
newInts[i] = otherInts[i];
} catch (...) {
delete [] newInts;
delete [] newChars;
throw;
}
return new MyData(newChars, newInts, nInts);
}
static MyData* clone(const MyData* otherData) {
return clone(otherData->theString,
otherData->theInts,
otherData->numInts);
}
static void cleanup(const MyData* theData) {
delete [] theData->theString;
delete [] theData->theInts;
delete theData;
}
public:
HasPointers(const char* someString, const int* someInts,
size_t numInts) {
theData = clone(someString, someInts, numInts);
}
HasPointers(const HasPointers& source) {
theData = clone(source.theData);
}
HasPointers& operator=(const HasPointers& rhs) {
if (this != &rhs) {
MyData* newData =
clone(rhs.theData->theString,
rhs.theData->theInts,
rhs.theData->numInts);
cleanup(theData);
theData = newData;
}
return *this;
}
~HasPointers() {
cleanup(theData);
}
friend ostream& operator<<(ostream& os,
const HasPointers& obj) {
os << obj.theData->theString << ": ";
for (size_t i = 0; i < obj.theData->numInts; ++i)
os << obj.theData->theInts[i] << ' ';
return os;
}
};
int main() {
int someNums[] = {1, 2, 3, 4};
size_t someCount = sizeof someNums / sizeof someNums[0];
int someMoreNums[] = {5, 6, 7};