C++ exceptions: throw, catch and stack unwinding

read_marks finds an empty line three calls below main, and neither it nor the two functions between it and main can do anything useful about it. C++ reports such a failure with an exceptionexception: An object thrown with throw to report that a function cannot do what it was asked. Control leaves the function at once and passes up the chain of callers to the first handler whose type matches the object.: the function creates an object that describes the problem and throws it, and control leaves at once for the nearest try block up the chain of callers that has a matching catch handler. On the way, stack unwindingstack unwinding: What happens while a thrown exception travels to its catch block: every local object constructed since the try block began, and not yet destroyed, is destroyed in reverse order before the handler runs. More in “Destructors and RAII in C++” destroys every local object of every function it leaves, newest first, so RAIIRAII: Resource acquisition is initialisation: a class acquires a resource, such as an open file or a locked mutex, in its constructor and releases it in its destructor, so every path out of the object's scope releases it exactly once. More in “Destructors and RAII in C++” objects still close their files and release their locks although no function returned normally. If no handler exists anywhere, the program calls std::terminate and ends.

Exceptions suit failures that the caller cannot sensibly check for at every step: a missing file, malformed input found deep inside a parser, memory that ran out. Below, one throw is traced through three functions with Apple clang 21 and GCC 16, caught four ways, matched against the standard classes, and stopped by noexcept and by builds without exceptions.

A throw leaves every function between it and the handler

A try block marks the code whose exceptions you want to handle, and the handlersexception handler: A catch block after a try block, such as catch (const std::out_of_range& e). The handlers are tried in the order they are written; the first whose type is the thrown type, or a public base class of it, runs, and catch (...) matches any exception. after it say which ones. When an exception reaches the block, its handlers are tried in the order they are written, and the first whose type matches runs: a handler for the same class as the exception, or for a public base class of it. A handler written catch (...) matches any exception at all. After the handler finishes, the program continues below the last handler of that try block; it never goes back to the code that threw.

Tracer prints + when it is created and - when it is destroyed. Three functions each create one and call the next, and the innermost one throws when the line it is given is empty:

#include <print>
#include <stdexcept>
#include <string_view>
#include "tracer.h"

void read_marks(std::string_view line) {
    Tracer buffer{"read_marks: buffer"};
    if (line.empty()) throw std::invalid_argument("empty line");
    std::println("  read_marks read \"{}\"", line);
}

void load_student(std::string_view line) {
    Tracer record{"load_student: record"};
    read_marks(line);
    std::println("  load_student finished");  // skipped when read_marks throws
}

void import_class(std::string_view line) {
    Tracer log{"import_class: log"};
    load_student(line);
    std::println("  import_class finished");  // skipped too
}

int main(int argc, char*[]) {
    if (argc > 1) {  // ./unwind uncaught: the same throw, and no catch anywhere
        std::println("an empty line, caught nowhere:");
        import_class("");
        return 0;
    }
    std::println("a good line:");
    import_class("Asha 82");
    std::println("an empty line, caught in main:");
    try {
        import_class("");
    } catch (const std::invalid_argument& e) {
        std::println("  main caught: {}", e.what());
    }
}

// Tracer prints a line when it is created and another when it is destroyed, so that stack unwinding becomes visible.
#pragma once
#include <print>
#include <string>
#include <utility>

class Tracer {
public:
    explicit Tracer(std::string name) : name_(std::move(name)) { std::println("  + {}", name_); }
    ~Tracer() { std::println("  - {}", name_); }
    Tracer(const Tracer&) = delete;
    Tracer& operator=(const Tracer&) = delete;

private:
    std::string name_;
};

from session import run

# The same three calls with both compilers: a good line, a throw that main catches, and a throw nobody catches.
run("""
clang++ -std=c++23 -Wall -Wextra unwind.cpp -o unwind && ./unwind
./unwind uncaught
g++-16 -std=c++23 -Wall -Wextra unwind.cpp -o unwind-gcc && ./unwind-gcc
./unwind-gcc uncaught
""")

$ clang++ -std=c++23 -Wall -Wextra unwind.cpp -o unwind && ./unwind
a good line:
  + import_class: log
  + load_student: record
  + read_marks: buffer
  read_marks read "Asha 82"
  - read_marks: buffer
  load_student finished
  - load_student: record
  import_class finished
  - import_class: log
an empty line, caught in main:
  + import_class: log
  + load_student: record
  + read_marks: buffer
  - read_marks: buffer
  - load_student: record
  - import_class: log
  main caught: empty line
$ ./unwind uncaught
an empty line, caught nowhere:
  + import_class: log
  + load_student: record
  + read_marks: buffer
libc++abi: terminating due to uncaught exception of type std::invalid_argument: empty line
[exit status 134]
$ g++-16 -std=c++23 -Wall -Wextra unwind.cpp -o unwind-gcc && ./unwind-gcc
a good line:
  + import_class: log
  + load_student: record
  + read_marks: buffer
  read_marks read "Asha 82"
  - read_marks: buffer
  load_student finished
  - load_student: record
  import_class finished
  - import_class: log
an empty line, caught in main:
  + import_class: log
  + load_student: record
  + read_marks: buffer
  - read_marks: buffer
  - load_student: record
  - import_class: log
  main caught: empty line
$ ./unwind-gcc uncaught
an empty line, caught nowhere:
  + import_class: log
  + load_student: record
  + read_marks: buffer
terminate called after throwing an instance of 'std::invalid_argument'
  what():  empty line
[exit status 134]

Step through the second run, the empty line that main catches: each row is one call with the Tracer it holds, and the order in which the three objects go is the point.

The first two runs show the normal path and stack unwinding:

• A good line. Each function finishes, and each Tracer is destroyed as its own function returns, so the - lines come out in the reverse order of the + lines.
• An empty line, caught in main. read_marks throws a std::invalid_argument. Before the handler in main runs, the three objects are destroyed, newest first: buffer, then record, then log. The two finished lines never print, because the rest of each function was skipped. e.what() returns the message given to the exception’s constructor.

Both compilers print exactly the same lines, because the order is fixed by the standard: as control passes from the throw to the handler, every local object constructed since the try block was entered is destroyed, in the reverse order of construction.

Without a handler, no destructor runs

The third run threw the same exception with no try block anywhere. Both programs printed the three + lines and then a message from their standard library, but no - line at all: not one destructor ran. Step through it and watch the three Tracer objects on the right:

The standard leaves this case to the implementation: when no matching handler is found, std::terminatestd::terminate: The function C++ calls when exception handling cannot go on, for example when no handler matches a throw or an exception tries to leave a noexcept function. By default it calls std::abort, which ends the program with SIGABRT. is called, and whether the stack is unwound first is implementation-defined. Both compilers here follow the Itanium C++ ABI, which throws in two phases. A search phase walks up the stack looking for a handler and changes nothing. Only if it finds one does a cleanup phase run the destructors on the way to it. With no handler, the cleanup phase never starts, and std::terminate sees the stack exactly as it was at the throw. The diagram puts the two outcomes side by side:

That has a practical consequence. A destructor that matters, such as one that writes the last buffered lines of a log, runs after an error only if something catches the error. A handler in main that catches const std::exception&, prints the message and returns a non-zero exit status therefore does two jobs: the user gets a readable message, and every destructor runs. Its cost is that the place of the throw is gone by the time the handler runs, which matters when you want a stack trace of the failure; the lesson on debugging crashes, later in this module, shows how to record the stack before the program ends.

Catching by value slices the exception, and throw e; does too

A program can throw any copyable type, but a purpose-made class is clearer than a bare int or string, rule E.14 of the C++ Core Guidelines says, because its type names the problem and its members carry the details. ParseError is a std::runtime_error that also knows the line where parsing failed. The same exception is caught here in four ways:

#include <print>
#include <stdexcept>
#include <string>

// A purpose-made exception type: a std::runtime_error that also knows where the problem is.
class ParseError : public std::runtime_error {
public:
    ParseError(const std::string& message, int line) : std::runtime_error(message), line_(line) {}
    int line() const noexcept { return line_; }

private:
    int line_;
};

void parse_settings() { throw ParseError("expected '=' after the key", 7); }

int main() {
    try {
        parse_settings();
    } catch (std::exception e) {  // by value: a new std::exception, copied from part of the ParseError
        std::println("by value:     {}", e.what());
    }

    try {
        parse_settings();
    } catch (const std::exception& e) {  // by reference: the object that was thrown
        std::println("by reference: {}", e.what());
    }

    for (bool copy : {false, true}) {
        try {
            try {
                parse_settings();
            } catch (const std::exception& e) {
                if (copy) throw e;  // throws a copy of the std::exception part
                throw;              // rethrows the ParseError itself
            }
        } catch (const ParseError& e) {
            std::println("{:<13} still a ParseError, line {}", copy ? "throw e;" : "throw;", e.line());
        } catch (const std::exception& e) {
            std::println("{:<13} only a std::exception now: {}", copy ? "throw e;" : "throw;", e.what());
        }
    }
}

from session import run

# Catching by value and by reference, then rethrowing with throw; and throw e;, with both compilers.
run("""
clang++ -std=c++23 -Wall -Wextra catching.cpp -o catching && ./catching
g++-16 -std=c++23 -Wall -Wextra catching.cpp -o catching-gcc && ./catching-gcc
""")

$ clang++ -std=c++23 -Wall -Wextra catching.cpp -o catching && ./catching
by value:     std::exception
by reference: expected '=' after the key
throw;        still a ParseError, line 7
throw e;      only a std::exception now: std::exception
$ g++-16 -std=c++23 -Wall -Wextra catching.cpp -o catching-gcc && ./catching-gcc
catching.cpp: In function 'int main()':
catching.cpp:20:29: warning: catching polymorphic type 'class std::exception' by value [-Wcatch-value=]
   20 |     } catch (std::exception e) {  // by value: a new std::exception, copied from part of the ParseError
      |                             ^
by value:     std::exception
by reference: expected '=' after the key
throw;        still a ParseError, line 7
throw e;      only a std::exception now: std::exception

Step through the four parts, with the thrown ParseError on the left and what each handler receives on the right:

• By value, catch (std::exception e) creates a new std::exception and copies into it only the std::exception part of the thrown ParseError. The copy is slicedslicing: What happens when an object of a derived class is copied into a variable or a parameter of a base class type: only the base part is copied, the derived members are left behind, and the copy behaves as a plain base object. More in “Virtual functions, override and virtual destructors”: its what() is the base class’s own message, std::exception with both libraries, and the line number is gone. GCC warns about it with -Wcatch-value, which -Wall turns on; Clang compiles it silently.
• By const reference, the handler sees the object that was thrown, with its real message. A handler for a base class can still reach the derived members with dynamic_cast, or by catching const ParseError& directly.
• throw; with no operand rethrowsrethrow: throw; with no operand, written inside a handler: it throws the exception being handled again, the same object with its full type, so an outer handler for the derived class still matches. throw e; throws a copy of e's static type instead. the exception being handled, the ParseError itself, so the outer handler for ParseError still matches.
• throw e; throws a new copy of e’s static typestatic type: The type the compiler sees for an expression, from the declarations alone: through a Shape* the object has the static type Shape, whatever it really is. Calls to ordinary member functions are chosen from it. More in “Virtual functions, override and virtual destructors”, std::exception, so the outer ParseError handler no longer matches and the line number is lost again.

Rule E.15 of the Core Guidelines sums it up: throw by value, catch exceptions from a class hierarchy by reference, usually const. Never write throw new ParseError(…), which throws a pointer that some handler must remember to delete.

Decide by the exception’s type, never by its message

The standard library reports its own failures with a small family of classes, all derived from std::exception, whose virtual what() returns a message:

std::logic_error is for mistakes the caller could have avoided by checking first, such as an index past the end. std::runtime_error is for failures that can only be found while the program runs, whatever the caller does, such as a missing file. Here eight library calls are made in turn, and each handler names the class it caught:

#include <cstddef>
#include <filesystem>
#include <new>
#include <print>
#include <stdexcept>
#include <string>
#include <vector>

// Runs one call and reports which standard exception came out of it. The handlers go from the most derived
// classes to std::exception, because the first handler that matches wins.
template <typename Call>
void report(const char* what, Call call) {
    try {
        call();
        std::println("{:<30} no exception", what);
    } catch (const std::out_of_range& e) {
        std::println("{:<30} out_of_range: {}", what, e.what());
    } catch (const std::invalid_argument& e) {
        std::println("{:<30} invalid_argument: {}", what, e.what());
    } catch (const std::length_error& e) {
        std::println("{:<30} length_error: {}", what, e.what());
    } catch (const std::runtime_error& e) {
        std::println("{:<30} a runtime_error: {}", what, e.what());
    } catch (const std::bad_alloc& e) {
        std::println("{:<30} bad_alloc: {}", what, e.what());
    } catch (const std::exception& e) {
        std::println("{:<30} another exception: {}", what, e.what());
    }
}

int main() {
    std::vector<int> marks{72, 64, 91};
    report("marks.at(2)", [&] { (void)marks.at(2); });
    report("marks.at(3)", [&] { (void)marks.at(3); });
    report("std::stoi(\"seventy\")", [] { (void)std::stoi("seventy"); });
    report("std::stoi(\"99999999999\")", [] { (void)std::stoi("99999999999"); });
    report("std::string(\"abc\").substr(5)", [] { (void)std::string("abc").substr(5); });
    report("marks.reserve(max_size + 1)", [&] { marks.reserve(marks.max_size() + 1); });
    report("operator new(1 PiB)", [] { ::operator delete(::operator new(std::size_t{1} << 50)); });
    report("file_size(\"missing.txt\")", [] { (void)std::filesystem::file_size("missing.txt"); });
}

from session import run

# Which standard exception each library call throws, and the message each standard library gives it.
run("""
clang++ -std=c++23 -Wall -Wextra standard.cpp -o standard && ./standard
g++-16 -std=c++23 -Wall -Wextra standard.cpp -o standard-gcc && ./standard-gcc
""")

$ clang++ -std=c++23 -Wall -Wextra standard.cpp -o standard && ./standard
marks.at(2)                    no exception
marks.at(3)                    out_of_range: vector
std::stoi("seventy")           invalid_argument: stoi: no conversion
std::stoi("99999999999")       out_of_range: stoi: out of range
std::string("abc").substr(5)   out_of_range: basic_string
marks.reserve(max_size + 1)    length_error: vector
operator new(1 PiB)            bad_alloc: std::bad_alloc
file_size("missing.txt")       a runtime_error: filesystem error: in file_size: No such file or directory ["missing.txt"]
$ g++-16 -std=c++23 -Wall -Wextra standard.cpp -o standard-gcc && ./standard-gcc
marks.at(2)                    no exception
marks.at(3)                    out_of_range: vector::_M_range_check: __n (which is 3) >= this->size() (which is 3)
std::stoi("seventy")           invalid_argument: stoi
std::stoi("99999999999")       out_of_range: stoi
std::string("abc").substr(5)   out_of_range: string::string: __pos (which is 5) > this->size() (which is 3)
marks.reserve(max_size + 1)    length_error: vector::reserve
operator new(1 PiB)            bad_alloc: std::bad_alloc
file_size("missing.txt")       a runtime_error: filesystem error: cannot get file size: No such file or directory [missing.txt]

Every failing call threw the same class with both libraries, the class the standard specifies for it: at and substr throw std::out_of_range for a position past the end, std::stoi throws std::invalid_argument when there is no number and std::out_of_range when the number does not fit in an int, reserve throws std::length_error, a failed allocation throws std::bad_alloc, and file_size throws std::filesystem::filesystem_error, which the std::runtime_error handler caught because it derives from std::system_error, a kind of std::runtime_error.

The messages are another matter. For marks.at(3), libc++ says vector, while libstdc++ says vector::_M_range_check: __n (which is 3) >= this->size() (which is 3). The standard specifies the class of each exception, never the text of its message, so code should decide what to do from the type it catches and show what() only to people.

The order of the handlers in report matters too. They go from the most derived classes to std::exception, because the first match wins: a std::logic_error handler placed before std::out_of_range would catch every out-of-range error itself. Rule E.31 of the Core Guidelines asks for exactly this order.

For your own exception types, derive from std::logic_error or std::runtime_error, or from one of their subclasses, and add the members a handler needs, as ParseError adds its line. Callers can then catch your exact type where they can do something specific, and std::exception where they only report.

An exception that leaves a noexcept function ends the program

noexceptnoexcept: A specifier that promises a function lets no exception out, as in Buffer(Buffer&&) noexcept. If one tries to leave such a function, std::terminate ends the program. A destructor is noexcept unless it says otherwise. More in “Destructors and RAII in C++” after a function’s parameters promises that no exception will leave the function. The compiler relies on the promise, and the standard backs it with a hard rule: if the search for a handler reaches the outermost block of a non-throwing function, std::terminate is called. checked_div breaks its promise:

#include <print>
#include <stdexcept>

int checked_div(int a, int b) noexcept {  // promises never to throw...
    if (b == 0) throw std::domain_error("division by zero");  // ...and breaks the promise
    return a / b;
}

int main() {
    try {
        std::println("{}", checked_div(10, 2));
        std::println("{}", checked_div(1, 0));
    } catch (const std::exception& e) {
        std::println("caught: {}", e.what());  // never reached
    }
}

from session import run

# A throw that leaves a noexcept function: both compilers warn, and both programs end in std::terminate.
run("""
clang++ -std=c++23 -Wall -Wextra noexcept_escape.cpp -o noexcept_escape && ./noexcept_escape
g++-16 -std=c++23 -Wall -Wextra noexcept_escape.cpp -o noexcept_escape-gcc && ./noexcept_escape-gcc
""")

$ clang++ -std=c++23 -Wall -Wextra noexcept_escape.cpp -o noexcept_escape && ./noexcept_escape
noexcept_escape.cpp:5:17: warning: 'checked_div' has a non-throwing exception specification but can still throw [-Wexceptions]
    5 |     if (b == 0) throw std::domain_error("division by zero");  // ...and breaks the promise
      |                 ^
noexcept_escape.cpp:4:5: note: function declared non-throwing here
    4 | int checked_div(int a, int b) noexcept {  // promises never to throw...
      |     ^                         ~~~~~~~~
1 warning generated.
5
libc++abi: terminating due to uncaught exception of type std::domain_error: division by zero
Abort trap: 6
[exit status 134]
$ g++-16 -std=c++23 -Wall -Wextra noexcept_escape.cpp -o noexcept_escape-gcc && ./noexcept_escape-gcc
noexcept_escape.cpp: In function 'int checked_div(int, int)':
noexcept_escape.cpp:5:17: warning: 'throw' will always call 'terminate' [-Wterminate]
    5 |     if (b == 0) throw std::domain_error("division by zero");  // ...and breaks the promise
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
5
terminate called after throwing an instance of 'std::domain_error'
  what():  division by zero
Abort trap: 6
[exit status 134]

Step through the run. main has a handler that matches the thrown std::domain_error, so watch whether it ever runs:

Both compilers see it coming, with Clang’s -Wexceptions and GCC’s -Wterminate, both on by default. At run time, the first call prints 5, and the second ends the program although main has a handler that matches: the exception never got past checked_div. Each library prints its own message, libc++’s terminating due to uncaught exception of type std::domain_error: division by zero and libstdc++’s terminate called after throwing an instance of 'std::domain_error' with the what() text below it. Both then abort the program: exit statusexit status: The number a program hands back when it ends, the value main returns. 0 means success; a shell keeps the last status in $?, and && runs the next command only after a status of 0. More in “How C++ compiles: preprocess, compile and link” 134 is 128 plus 6, the number of SIGABRT.

The same ending awaits an exception that leaves main, as the third run of the unwinding example showed, and one that leaves a destructor, because destructors are noexcept by default. So mark a function noexcept only when it really cannot throw, as moves, swaps and destructors should not.

Without exceptions, errors have to travel as values

Some large code bases build with -fno-exceptions. The LLVM project does, to reduce code and executable size, and Google’s C++ style guide does not use exceptions at all. In such a build, throw and try no longer compile, and a library function that would throw has no way to report its error:

#include <stdexcept>

int checked_percent(int marks) {
    if (marks < 0 || marks > 100) throw std::out_of_range("marks must be 0 to 100");
    return marks;
}

int main() { return checked_percent(72) == 72 ? 0 : 1; }

#include <print>
#include <vector>

int main() {
    std::vector<int> marks{72, 64, 91};
    std::println("{}", marks.at(1));
    std::println("{}", marks.at(3));  // at() checks the index and would throw std::out_of_range
    std::println("not reached");
}

from session import run

# Builds with exceptions turned off: throw no longer compiles, and a library call that would throw ends the program.
run("""
clang++ -std=c++23 -fno-exceptions thrower.cpp -o thrower
g++-16 -std=c++23 -fno-exceptions thrower.cpp -o thrower-gcc
clang++ -std=c++23 -fno-exceptions bounds.cpp -o bounds && ./bounds
g++-16 -std=c++23 -fno-exceptions bounds.cpp -o bounds-gcc && ./bounds-gcc
""")

$ clang++ -std=c++23 -fno-exceptions thrower.cpp -o thrower
thrower.cpp:4:35: error: cannot use 'throw' with exceptions disabled
    4 |     if (marks < 0 || marks > 100) throw std::out_of_range("marks must be 0 to 100");
      |                                   ^
1 error generated.
[exit status 1]
$ g++-16 -std=c++23 -fno-exceptions thrower.cpp -o thrower-gcc
thrower.cpp: In function 'int checked_percent(int)':
thrower.cpp:4:83: error: exception handling disabled, use '-fexceptions' to enable
    4 |     if (marks < 0 || marks > 100) throw std::out_of_range("marks must be 0 to 100");
      |                                                                                   ^
[exit status 1]
$ clang++ -std=c++23 -fno-exceptions bounds.cpp -o bounds && ./bounds
64
Abort trap: 6
[exit status 134]
$ g++-16 -std=c++23 -fno-exceptions bounds.cpp -o bounds-gcc && ./bounds-gcc
64
terminate called after throwing an instance of 'std::out_of_range'
  what():  vector::_M_range_check: __n (which is 3) >= this->size() (which is 3)
Abort trap: 6
[exit status 134]

The two toolchains agree about your own throw and disagree about the library’s:

Both compilers reject throw, each with its own wording. The call to at(3) ends both programs, in different ways. libc++’s headers replace the throw with a plain abort(), which prints nothing. libstdc++’s range check lives in its compiled library, which was built with exceptions, so the exception is thrown anyway, finds no handler in code compiled without them, and std::terminate prints the usual message. Either way, code built like this reports its errors as values instead: std::expected and error codes, the subject of a later lesson in this module.

Practise: a safe_divide that reports division by zero

divide.h declares DivisionByZero, a std::domain_error whose message names the number that could not be divided, and three functions that do not use it yet:

// Your turn (lesson cpp/exceptions-basics): make safe_divide report a zero divisor with an exception, and make
// class_averages recover from it. The sample tests are in divide_tests.cpp.
#pragma once
#include <stdexcept>
#include <string>
#include <utility>
#include <vector>

// What safe_divide throws. It is a std::domain_error, so a caller can also catch it as a std::logic_error or a
// std::exception, and what() names the dividend: "cannot divide 84 by zero".
class DivisionByZero : public std::domain_error {
public:
    explicit DivisionByZero(int dividend)
        : std::domain_error("cannot divide " + std::to_string(dividend) + " by zero"), dividend_(dividend) {}
    int dividend() const noexcept { return dividend_; }

private:
    int dividend_;
};

// TODO 1: when divisor is 0, throw DivisionByZero{dividend} instead of returning 0.
inline int safe_divide(int dividend, int divisor) {
    if (divisor == 0) return 0;
    return dividend / divisor;
}

struct ClassMarks {
    std::string name;
    int total_marks;
    int students;
};

struct Averages {
    std::vector<std::pair<std::string, int>> averages;  // the class and its average, for every class with students
    std::vector<std::string> skipped;                   // the classes that have no students
};

// TODO 2: a class with no students has no average. Catch DivisionByZero for that one class (by const reference),
// add the class's name to skipped and go on with the next class. Let every other exception reach the caller.
inline Averages class_averages(const std::vector<ClassMarks>& classes) {
    Averages result;
    for (const ClassMarks& c : classes) result.averages.emplace_back(c.name, safe_divide(c.total_marks, c.students));
    return result;
}

// TODO 3: the exit status of a report program: 0 when every class has an average, 2 when any class was skipped.
inline int exit_status(const Averages& result) {
    (void)result;
    return 0;
}

// Sample tests for divide.h. Build: clang++ -std=c++23 -Wall -Wextra divide_tests.cpp -o divide_tests
#include <print>
#include <stdexcept>
#include <string>
#include <utility>
#include <vector>
#include "divide.h"

int passed = 0;
int failed = 0;

void expect(bool ok, const char* what) {
    if (ok) {
        ++passed;
    } else {
        ++failed;
        std::println("FAIL {}", what);
    }
}

int main() {
    expect(safe_divide(84, 4) == 21, "safe_divide(84, 4) is 21");

    bool threw = false;
    std::string message;
    int dividend = 0;
    try {
        (void)safe_divide(7, 0);
    } catch (const DivisionByZero& e) {
        threw = true;
        message = e.what();
        dividend = e.dividend();
    }
    expect(threw, "safe_divide(7, 0) throws DivisionByZero");
    expect(message == "cannot divide 7 by zero" && dividend == 7, "the exception names the dividend 7");

    bool as_logic_error = false;
    try {
        (void)safe_divide(1, 0);
    } catch (const std::logic_error&) {
        as_logic_error = true;
    }
    expect(as_logic_error, "the exception can be caught as a std::logic_error");

    std::vector<ClassMarks> classes{{"9A", 840, 20}, {"9B", 0, 0}, {"9C", 1000, 25}};
    Averages result = class_averages(classes);
    std::vector<std::pair<std::string, int>> want{{"9A", 42}, {"9C", 40}};
    expect(result.averages == want && result.skipped == std::vector<std::string>{"9B"},
           "class_averages skips 9B, which has no students, and keeps 9A and 9C");
    expect(exit_status(result) == 2, "the exit status is 2 when a class was skipped");
    expect(exit_status(class_averages({{"10A", 750, 25}})) == 0, "the exit status is 0 when every class has an average");

    std::println("{} of {} checks passed", passed, passed + failed);
    return failed == 0 ? 0 : 1;
}

from session import run

# The sample tests against the starter code, before the TODOs are done.
run("""
clang++ -std=c++23 -Wall -Wextra divide_tests.cpp -o divide_tests && ./divide_tests
g++-16 -std=c++23 -Wall -Wextra divide_tests.cpp -o divide_tests-gcc && ./divide_tests-gcc
""")

$ clang++ -std=c++23 -Wall -Wextra divide_tests.cpp -o divide_tests && ./divide_tests
FAIL safe_divide(7, 0) throws DivisionByZero
FAIL the exception names the dividend 7
FAIL the exception can be caught as a std::logic_error
FAIL class_averages skips 9B, which has no students, and keeps 9A and 9C
FAIL the exit status is 2 when a class was skipped
2 of 7 checks passed
[exit status 1]
$ g++-16 -std=c++23 -Wall -Wextra divide_tests.cpp -o divide_tests-gcc && ./divide_tests-gcc
FAIL safe_divide(7, 0) throws DivisionByZero
FAIL the exception names the dividend 7
FAIL the exception can be caught as a std::logic_error
FAIL class_averages skips 9B, which has no students, and keeps 9A and 9C
FAIL the exit status is 2 when a class was skipped
2 of 7 checks passed
[exit status 1]

Make all 7 checks pass with both compilers:

1. In safe_divide, throw DivisionByZero{dividend}; when divisor is 0. Throw the object itself, by value.
2. In class_averages, put the call for one class inside a try block in the loop, and catch const DivisionByZero& there: add the class’s name to skipped and let the loop go on. Do not catch std::exception, so that any other error still reaches the caller.
3. In exit_status, return 2 when skipped is not empty, and 0 otherwise, so that a script that runs the report can tell a partial result from a complete one.

The check that catches std::logic_error passes only because DivisionByZero derives from std::domain_error, which derives from std::logic_error: a handler for a base class matches every class below it.

Finish with the self-check on the six ideas above, from the first matching handler to builds without exceptions. It starts where your answers have been weakest and explains each choice as soon as you make it:

Interview questions

Fresher · Why do you throw by value and catch by const reference?

Throwing by value, as in throw ParseError{"missing key", 7};, lets the runtime own a copy of the exception for as long as handlers need it, with nothing to delete. Catching by reference then refers to that object itself. Catching by value instead copies only the part the handler names: catch (std::exception e) slices a ParseError down to a plain std::exception, so what() loses its message and the extra members are gone, and GCC warns about it with -Wcatch-value. const adds that handlers rarely need to change the exception. A good answer adds the rethrow rule: throw; passes on the original object, while throw e; throws a sliced copy. Both rules are E.15 of the C++ Core Guidelines.

The follow-ups usually test the two mistakes this answer rules out: throwing a pointer, and reaching the derived members from a base-class handler. Decide both:

Two design questions of this module start from this lesson: a batch job that dies with exit status 134 and loses the last lines of its log, and the exception classes of a library that several teams will use.

Key takeaways

• throw sends an exception up the call chain to the first matching handler; the handlers of a try block are tried in order, so put derived classes before their bases.
• Stack unwinding destroys every local object between the throw and the handler, newest first. With no handler at all, both compilers call std::terminate before any destructor runs.
• Throw by value and catch by const reference: catching by value slices the exception, and throw e; slices a rethrow, while throw; keeps the original.
• Derive your exceptions from std::logic_error or std::runtime_error and decide by type, never by parsing what(): the two standard libraries word their messages differently.
• An exception that leaves a noexcept function, a destructor or main calls std::terminate, which aborts with exit status 134.
• With -fno-exceptions, throw does not compile and a library call that would throw ends the program, so errors have to travel as values.