Exceptions and the Call Stack

In this lesson, we’ll begin to see how exception handling is helpful in larger programs, due to its close connection to the call stack.

In previous examples, our catch statements were always catching exceptions from a function that was directly called within the corresponding try block:

1void SomeFunction() {
2  throw std::runtime_error;
3}
4
5void AnotherFunction() {
6  try {
7    SomeFunction();
8  } catch (...) {
9    std::cout << "Caught!";
10  }
11}
12

But, this need not be the case. The error can be caught right away, in the same stack frame:

1void SomeFunction() {
2  try {
3    throw std::runtime_error;
4  } catch (...) {
5    std::cout << "Caught!";
6  }
7}
8

More usefully, the exception can be caught in any underlying stack frame:

1void SomeFunction () {
2  throw std::runtime_error;
3}
4
5void AnotherFunction() {
6  SomeFunction();
7}
8
9int main() {
10  try {
11    AnotherFunction();
12  } catch (...) {
13    std::cout << "Caught!";
14  }
15}
16

This is the true power of exceptions - it gives us the ability to handle errors in a flexible and intuitive way.

throw and Unreachable Code

When a throw expression is encountered during the running of our application, the program immediately exits the current try block and searches for the closest catch statement that can handle the type of exception thrown.

This is demonstrated in the following example:

1void MyFunction() {
2  try {
3    throw std::runtime_error;
4    std::cout << "A"; // Unreachable
5  } catch (...) {
6    std::cout << "B";
7  }
8  std::cout << "C";
9}
10

1BC
2

The throw on line 3 makes the rest of the try block unreachable, so “A” is not logged. The catch block in this function can handle the type of exception thrown, so “B” is logged out.

Finally, because our function recovered, execution continues, and “C” is logged out as normal.

1void MyFunction() {
2  int* MyInt { new Int { 2 } };
3  SomeFunction();
4  delete MyInt;
5}
6

Stack Unwinding

If the exception is not handled within the function that threw it, that function’s stack frame is immediately popped off the stack. Here are three examples of where that would happen:

1void MyFunction() {
2  // Uncaught exception
3  throw std::runtime_error;
4  
5  // This stack frame will be popped before reaching here
6  std::cout << "I'm unreachable";
7}
8

1void MyFunction() {
2  try {
3    // ...
4  } catch (...) {
5    // ...
6  }
7  // Exception thrown outside a try block
8  throw std::runtime_error;
9
10  // This stack frame will be popped before reaching here
11  std::cout << "I'm unreachable";
12}
13

1void MyFunction() {
2  // No catch block matching the type of exception thrown
3  try {
4    throw std::runtime_error;
5  } catch (std::logic_error& e) {
6    // ...
7  }
8  
9  // This stack frame will be popped before reaching here
10  std::cout << "I'm unreachable";
11}
12

In all three cases, the MyFunction stack frame is popped off the stack. From there, the search for an appropriate catch statement continues on the next stack frame - the function that called our function:

1void CallingFunction() {
2  // Is there a try block wrapping this,
3  // with an appropriate catch?
4  MyFunction();
5  // If not, I will be popped off the stack, and
6  // the search will continue at the next level
7  // of the stack - the function that called me
8}
9

If the exception thrown from the call to MyFunction wasn’t caught in CallingFunction, it too is popped off the stack, and the search continues at the function that called CallingFunction.

This process repeats until an appropriate catch is found. If the process reaches main, and that too is unable to handle the exception, the program terminates.

This recursive process is commonly referred to as unwinding the stack.

std::terminate()

When our application has an unhandled exception, it terminates.

However, we can also trigger this termination ourselves, using std::terminate, available from the <exception> header.

This is mostly useful if our code encounters an error it knows is irrecoverable, and wants to close as quickly as possible, bypassing any possible catch statements that might attempt recovery.

1#include <exception>
2#include <iostream>
3
4void MyFunction() { std::terminate(); }
5
6int main() {
7  try {
8    MyFunction();
9  } catch (...) {
10    std::cout << "Caught!";
11  }
12}
13

1C:\examples\exceptions.exe (process 69992) exited with code 3.
2

Note how “Caught!” is not logged

std::set_terminate() and std::abort()

By default, std::terminate simply calls another function, std::abort(), to close our application.

However, we can define our program’s terminate handler ourselves, by passing a function to std::set_terminate.

We cannot attempt to recover from within a terminate handler. Our custom handler still needs to call std::abort(), but it doesn’t have to call it immediately - we can do other things first.

1#include <exception>
2#include <iostream>
3
4void MyFunction() { throw 1; }
5
6int main() {
7  std::set_terminate([]() {
8    std::cout << "Goodbye!";
9    std::abort();
10  });
11
12  MyFunction();
13}
14

1Goodbye!
2C:\examples\exceptions.exe (process 69992) exited with code 3.
3

In large-scale projects, terminate handlers are most commonly used to generate reports containing additional information about the crash, which may help us debug.

These are typically called crash dumps, and they include information like what the unhandled exception was, the value of important variables, the call stack, hardware configuration, and more.

noexcept Functions

Within our program, we can mark functions as noexcept:

1void SomeFunction() noexcept {
2  // ...
3}
4

These functions should not throw an exception to their caller. Note, we can still throw exceptions within these functions, or in the functions they call. The noexcept specifier is just stating that an exception will not be thrown to the caller.

If a noexcept function does throw an exception to the caller, std::terminate will be called, bypassing any attempts to catch that exception.

Using noexcept correctly has 3 potential benefits:

1. It serves as documentation - anyone scanning our code will quickly see that the function will not throw exceptions.
2. The compiler may be able to better optimize the resulting binary
3. Some algorithms can be more performant when they are passed a noexcept function

It is possible to pass a boolean to the noexcept specifier, to determine whether or not it applies.

For example, noexcept(true) is equivalent to noexcept and noexcept(false) is equivalent to not having the specifier there at all.

We can pass any boolean expression to this handler, as long as it can be evaluated at compile time.

1constexpr bool SomeBoolean{true};
2void SomeFunction() noexcept(SomeBoolean) {
3  // ...
4}
5