Chapter 15

You might be wondering what happens when you add inheritance into the mix. Superclass constructors run before subclass constructors. If a subclass constructor throws an exception, how are the resources that the superclass constructor allocated freed? The answer is that C++ guarantees that it will run the destructor for any fully constructed “subobjects.” Therefore, any constructor that completes without an exception will cause the corresponding destructor to be run.

Errors in Destructors

You should handle all error conditions that arise in destructors in the destructors themselves. You should not let any exceptions be thrown from destructors, for three reasons:

1.Destructors can run while there is another pending exception, in the process of stack unwinding. If you throw an exception from the destructor while another exception is active, the program will terminate. For the brave and curious, C++ does provide the ability to determine, in a destructor, whether you are executing as a result of a normal function exit or delete call, or because of stack unwinding. The function uncaught_exception(), declared in the <exception> header file, returns true if there is an uncaught exception and you are in the middle of stack unwinding. Otherwise, it returns false. However, this approach is messy and should be avoided.

2.What action would clients take? Clients don’t call destructors explicitly: they call delete, which calls the destructor. If you throw an exception from the destructor, what is a client supposed to do? It can’t call delete on the object again, and it shouldn’t call the destructor explicitly. There is no reasonable action the client can take, so there is no reason to burden that code with exception handling.

3.The destructor is your one chance to free memory and resources used in the object. If you waste your chance by exiting the function early due to an exception, you will never be able to go back and free the memory or resources.

Therefore, be careful to catch in a destructor any exceptions that can be thrown by calls you make from the destructor. Normally, destructors call only delete and delete[], which cannot throw exceptions, so there should be no problem.

Putting It All Together

Now that you’ve learned about error handling and exceptions, here is the entire GameBoard class from Chapter 11 retrofitted with exceptions.

First, here is the class definition:

#include <stdexcept> #include <new>

using std::bad_alloc; using std::out_of_range;

class GameBoard

{

public:

GameBoard(int inWidth = kDefaultWidth, int inHeight = kDefaultHeight) throw(bad_alloc);

GameBoard(const GameBoard& src) throw(bad_alloc); ~GameBoard() throw();

428

Handling Errors

GameBoard& operator=(const GameBoard& rhs) throw(bad_alloc);

void setPieceAt(int x, int y, const GamePiece& inPiece) throw(out_of_range);

GamePiece& getPieceAt(int x, int y) throw(out_of_range);

const GamePiece& getPieceAt(int x, int y) const throw(out_of_range);

int getHeight() const throw() { return mHeight; } int getWidth() const throw() { return mWidth; }

static const int kDefaultWidth = 100; static const int kDefaultHeight = 100;

protected:

void copyFrom(const GameBoard& src) throw(bad_alloc);

GamePiece** mCells; int mWidth, mHeight;

};

The constructors and operator= all throw bad_alloc because they perform memory allocation. The destructor, getHeight(), and getWidth() throw no exceptions. setPeiceAt() and getPieceAt() throw out_of_range if the caller supplies an invalid width or height.

You’ve already seen the implementation of the constructor in the previous section. Here are the implementations of the copyFrom(), setPieceAt(), and getPieceAt() methods with exception handling. The implementations of the copy constructor and operator= did not change except for their throw lists because all the work is in copyFrom(), so their implementations are not shown. The destructor also did not change, so its implementation is not shown. Refer to Chapter 11 for details.

void GameBoard::copyFrom(const GameBoard& src) throw(bad_alloc)

{

int i, j;

mWidth = src.mWidth; mHeight = src.mHeight;

mCells = new GamePiece *[mWidth];

try {

for (i = 0; i < mWidth; i++) { mCells[i] = new GamePiece[mHeight];

}

}catch (...) {

//Clean up any memory we already allocated.

//If this function is called from the copy constructor,

//the destructor will never be called.

//Use the same upper bound on the loop as described in the constructor. for (j = 0; j < i; j++) {

delete [] mCells[j];

}

delete [] mCells;

//Set mCells and mWidth to values that will allow the

//destructor to run without harming anything.

//This function is called from operator=, in which case the

429

Chapter 15

//object was already constructed, so the destructor will be

//called.

mCells = NULL;

mWidth = 0;

throw bad_alloc();

}

for (i = 0; i < mWidth; i++) {

for (j = 0; j < mHeight; j++) { mCells[i][j] = src.mCells[i][j];

}

}

}

void GameBoard::setPieceAt(int x, int y, const GamePiece& inElem)

throw(out_of_range)

{

// Check for out of range arguments.

if (x < 0 || x >= mWidth || y < 0 || y >= mHeight) {

throw out_of_range(“Invalid width or height”);

}

mCells[x][y] = inElem;

}

GamePiece& GameBoard::getPieceAt(int x, int y) throw(out_of_range)

{

// Check for out of range arguments.

if (x < 0 || x >= mWidth || y < 0 || y >= mHeight) { throw out_of_range(“Invlalid width or height”);

}

return (mCells[x][y]);

}

const GamePiece& GameBoard::getPieceAt(int x, int y) const throw(out_of_range)

{

// Check for out of range arguments.

if (x < 0 || x >= mWidth || y < 0 || y >= mHeight) { throw out_of_range(“Invlalid width or height”);

}

return (mCells[x][y]);

}

Summar y

This chapter described the issues related to error handling in C++ programs, and emphasized that you must design and code your programs with an error-handling plan. By reading this chapter, you learned the details of C++ exceptions syntax and behavior. The chapter also covered some of the areas in which error handling plays a large role, including I/O streams, memory allocation, constructors, and destructors. Finally, you saw an example of error handling in the GameBoard class.

The next few chapters continue to cover advanced C++ language topics. Chapter 16 describes operator overloading, Chapter 17 covers performance issues in C++, and Chapter 18 teaches you how to combine C++ with other languages and run your programs on multiple platforms.

430