Exception safety

Exception safety is about taking care of the resources that you are using, such as allocated memory or opened files, both in the happy path through your code and in the case of an exception being thrown.

The problem lies in code such as

What happens to the memory which is allocated dynamically for the array if the function bar throws an exception? What surprises many developers is that the execution will skip all code lines after the call to bar in the local function and continue with the first line in the appropriate exception handler. The line where the dynamically array is deleted (using delete[]) is not going to be called at all! This means that the code in the example above is not exception safe, when an exception is thrown then the code will leak memory.

Even though all code lines after the call to bar will be skipped, all the local variables (i.e. allocated on the stack) declared in the function foo are going to be cleaned up. And this is a feature which C++ uses to deal with exception safety. The technique is called RAII (Resource Acquisition is Initialization) and stores variables and data structures on the local stack instead of on the free store directly. Now you object that it is impossible to always store all the data on the stack, you may not know how much data you are going to need when you write the program. The size of a variable is something which you probably want to determine at run time, depending on the input data to your program.

The C++ solution to this is to store a handle to the memory that you have allocated on the free store on the local stack. When that handle goes out of scope its destructor will be called and you simply make sure that you delete all the memory used in the destructor. This is the basic concept of the standard library containers, such as vector, list or map, or the smart pointers shared_ptr and unique_ptr.  To convert the example above into exception safe code, replace the call to the dynamic memory allocation into using std::vector like this.

The instance of the vector is allocated on the local stack, but internally it will call new[] to allocate the memory for the 25 values on the free store. When the vector goes out of scope, either because the function ends or an exception is thrown, then the destructor of the vector is going to be called and this will delete all the memory that was allocated on the free store.

The C++ standard library containers and data structures all use the RAII technique for making sure that no resources are being leaked. When you create a new class you should also use the RAII technique to make sure your code is exception safe. Other developers who are using or modifying your code expect that you have taken care of releasing the resources that you are using and don’t want to worry about cleaning up the mess after you. Make the C++ code that you write developer friendly and clean up your own mess!

Facebookgoogle_pluslinkedinmail

Stack Unwinding

Stack unwinding refers to the handling of exceptions in C++. When an exception occurs then the call stack is searched for the next matching catch statement and the execution of the program is continued at the beginning of the catch clause. No other code in between is ever evaluated.

This is to say that for the functions

Then the program will never output any of the output statements!

However, and this is important, if the function f3() above did instead look like this:

then the cout statement would not be called, but the destructor of Date would be called. All local objects will be destructed when an exception happens, in the reverse order they were constructed.

 

Facebookgoogle_pluslinkedinmail

Memory leaks in constructions

Say that you have found somewhere deep in the darkest basement the following line of code

then you have found a potential memory leak in your program.

Why?

Remember that, calling new Date() will:

  1. Allocate memory for Date
  2. Construct the new Date object in that memory. If the construction fails because of an exception, then the allocated memory is freed again.

The compiler is free to evaluate the expressions in any way it seems suitable (the reason for this is that it has the ability to optimize the code if given some slack, see order of evaluation).  It can for example do like this:

  1. Allocate memory for Date
  2. Construct Date
  3. Allocate memory for Time
  4. Construct Time
  5. Call fun

The problem here is that if either step 3 or step 4 fails because of an exception, the C++ standard does not require that the Date object must be destroyed and its memory deallocated. This is a memory leak!

Another possibility is that the compiler does this:

  1. Allocate memory for Date
  2. Allocate memory for Time
  3. Construct Date
  4. Construct Time
  5. Call fun

In this case, then there are actually two problems.

1) If step 3 fails because of an exception, then the memory allocated for Date is automatically deallocated (step 1 is undone), but the standard does not require that the memory allocated for the Time object be deallocated. The memory is for the Time object is leaked.

2) If step 4 fails because of an exception, then the Date object has been allocated and fully constructed, but the standard does not require that it be destroyed and its memory deallocated. The memory of the Date object is leaked.

 

 

 

 

Facebookgoogle_pluslinkedinmail