CSE2305 - Object-Oriented Software Engineering
Week 11

Topic 21: C++ Exceptions

Synopsis

Run-time errors
What should happen?
Why doesn't that happen?
Error handling schemes
Exceptions ^¤
Setting up a try block
Throwing exceptions ^¤
Catching exceptions ^¤
Catching classes ^¤ of exceptions^¤
Uncaught exceptions ^¤
Example: new
Example: Array class ^¤
Reading

Run-time errors

What happens when an error occurs?
Segmentation fault
Bus error
Core dump
"Silent wrongness"

**What should happen?**

Program should diagnose error...
...handle it quietly if possible...
...or exit gracefully if necessary

Why doesn't that happen?

Error-handling code is tedious...
...to write
...to maintain
It "bloats" programs, obscures the algorithm, and slows them down

Error handling schemes

Vetting data before use
Return values of functions
Compile-time constraints
Assertions
Exceptions^¤

Exceptions ^¤

Normally control flows in and back out of nested functions
E.g. main() calls a.GetValue(), which calls a.myData.Get(), which calls cin.operator>>(), etc.
Exceptions^¤ give us a way of doing a "multi-level return" to some higher point in the calling sequence, where the error can be handled
The advantage is that the interim functions don't need to handle (or even know about) errors

Setting up a try block

We use exceptions^¤ by placing a "net" around a potentially fallible piece of code
Then any error messages originating from functions called inside the net, are caught by the net

In C++, this net is called a "try block" and looks like this:

void must_succeed(int data)
{
        do_something_safe();

	List<int> list;
	list.Append(data);

	try
	{
		data = do_something_risky(data);
		list.RiskyMethod(data);

		// OTHER RISKY STUFF
	}

	list.SafeMethod();
}

Throwing exceptions ^¤

Functions which can detect their own failure then throw out a distress call (an "exception^¤"), which gets caught in any surrounding "net" (i.e. in the nearest surrounding try block)

Exceptions^¤ are thrown with the throw statement:

class DivByZero
{};

int do_something_risky(int data)
{
	if (data==0)
	{
		DivByZero exception;
		throw exception;
	}
	return data-1/data;
}

Note that the exception^¤ thrown is actually an object, which can be used to send back useful information:

class NegativeIndex
{
public:
	NegativeIndex(int index, string context)
	: myIndex(index), myContext(context)
	{}

	int    myIndex;
	string myContext;
};

template <DATATYPE>
DATATYPE
List<DATATYPE>::RiskyMethod(int index)
{
	if (index<0)
	{
		NegativeIndex exception(index,"do_something_risky(int)");
		throw exception;
	}
	return myValues[index];
}

Catching exceptions ^¤

Exceptions^¤ which have been thrown may be caught by specifying one or more catch blocks after a try block:

try
{
	data = do_something_risky(data);
	list.RiskyMethod(data);

	// OTHER RISKY STUFF
}
catch (DivByZero)
{
	cout << "Can't divide by zero, stupid!" << endl;
}
catch (NegativeIndex exception)
{
	cout << "Can't access element " << exception.myIndex
	     << " in function " << exception.myContext << endl;
}
catch (...)
{
	cout << "Don't know what you did, but it was bad!" << endl;
}

The sequence of catch blocks acts almost like a switch which is triggered by an exception^¤ inside the try block (except that the sequence "switches" on the type of the exception^¤, not its value).
The third catch block catches any type of exception^¤.
If no catch block is specified for a particular kind of exception^¤, it "slips through the net" and continues propagating up the call sequence.
Note that as the exeception propagates, it causes functions it passes up through to terminate, and hence to call the destructors^¤ of any local objects
This behaviour^¤ is known as "stack unwinding"

Catching classes ^¤ of exceptions^¤

You can also specify reference^¤ and pointer types as catch targets:

try
{
	data = do_something_risky(data);
	list.RiskyMethod(data);

	// OTHER RISKY STUFF
}
catch (NumericException&)
{
		cout << "You did something dumb with a number!" << endl;
}
catch (IndexException& exception)
{
	cout << exception.Message() << endl;
}

Now, any exception^¤ class^¤ which is, or is derived from, a NumericException or an IndexException will be caught.

So you can set up families of exceptions^¤:

class NumericException
{};

class DivByZero : public NumericException
{};

class NegativeLog: public NumericException
{};

...and even use polymorphism^¤ to process them:

class IndexException
{
public:
	virtual string Message(void)
	{
		return "You did something stupid with an index";
	}
};

class NegativeIndex : public IndexException
{
public:
	NegativeIndex(int index, string context)
	: myIndex(index), myContext(context)
	{}

	virtual string Message(void)
	{
		stringstream message;
		message << "Can't index element "
			<< myIndex
			<< " (like you tried to do in "
			<< myContext
			<< ", dopey!";

		return message.str();
	}

	int    myIndex;
	string myContext;
};

Uncaught exceptions ^¤

If a propagating exception^¤ is not caught by any try-catch "net", then it propagates all the way out of main()
In that case the program terminates, usually with an "uncaught exception^¤" error message.

Example: `new`

The new operator uses exceptions^¤ to signal problems (unlike malloc which just returns a zero in such cases)
The exception^¤ is of class^¤ bad_alloc

So if you want to allocate memory and catch the cases where it failed, you need:

try
{
        ptr = new SomeClass;
}
catch (bad_alloc)
{
	// DO SOMETHING ABOUT IT
}

Example: Array class ^¤

Of course, if you're writing your own classes^¤ you can also use exceptions^¤ to signal problems:

template <class ELEMENTTYPE>
class Array
{
public:
	struct OutOfRange
	{
		int bad_index;
	};
	// YADDA YADDA

	ELEMENTTYPE operator[](int index)
	{
		if (index<0 || index>=mySize)
		{
			OutOfRange oor;
			oor.bad_index = index;
			throw oor;
		}
		return myData[index];
	}

	// YADDA YADDA
};

Then users of your code could catch that exception^¤:

Array<int> ai;

// AND LATER...

int nextindex;
while (cin >> nextindex)
{
	try
	{
		cout << ai[nextindex] << endl;
	}
	catch (Array<int>::OutOfRange exception)
	{
		cout << "Index " << exception.bad_index
		     << "was not in allowed range;
	}
}

Reading

Lippmann & Lajoie: Chapters 11, 2.8, 8.4, 19.2
Stroustrup: Chapter 14

Topic 21: C++ Exceptions

Synopsis

Catching classes¤ of exceptions¤

Catching classes ^¤ of exceptions^¤