Exceptions

What it is and why it exists

A C++ exception combines an exception object with a non-local transfer of control. A throw expression creates the exception object and stops the current normal path; the runtime searches the call chain for a type-compatible handler. A matching catch takes control and can recover, translate the failure, or propagate the same exception outward.

This mechanism separates the place that detects a failure from the place that decides what to do about it. A parsing function knows why input is invalid, but it may not know whether to retry, display a message, or abandon a request; its caller owns that policy. Exceptions are especially natural when a constructor cannot establish an object’s invariant because constructors have no ordinary return value for an error.

Exceptions fit cases where an operation cannot fulfill its contract and the current layer cannot recover. Bounds-checked standard-library operations, allocation, streams, and user-defined domain operations can use them. You also meet exception propagation or translation around std::future::get(), plugin boundaries, and top-level request handlers.

Exceptions are not the default answer for every failure. Expected branches such as a missing lookup result or temporarily unavailable input often fit std::optional, std::expected, error codes, or ordinary conditions better. The interface should expose the result callers need to handle instead of disguising a routine branch as an unexpected fault.

How it works

Executing throw expression; initializes an exception object. Its type participates in handler matching, and the object lives independently of locals at the throw site. The runtime first checks handlers that dynamically enclose the throw point; when none matches, it continues into callers.

Handlers are tried in source order. The same type, an unambiguous accessible base, and certain standard pointer conversions can match; catch (...) matches any exception. A derived-exception handler must therefore precede its base handler, and a catch-all handler must come last.

As the search proceeds outward, stack unwinding takes place. Fully constructed automatic objects are destroyed in reverse construction order. Control does not return to skipped statements, so cleanup must be attached to object destruction instead of relying on one manual call at the end of a function.

One propagation can be summarized as follows:

1. throw initializes the exception object from its operand.
2. The runtime checks the dynamically enclosing handlers in source order.
3. If none matches, fully constructed automatic objects in the exited scope are destroyed.
4. A match initializes the catch parameter and runs the handler.
5. The exception object is destroyed when nothing refers to it after the handler; a bare throw; can rethrow it first.

Resource Acquisition Is Initialization (RAII) turns unwinding into a reliable cleanup path. std::vector, std::string, smart pointers, file streams, and lock guards release ownership in their destructors. Once a resource belongs to such an object, a later exception cannot bypass its release logic.

If an exception leaves a noexcept function, or another exception escapes a destructor during propagation, the program calls std::terminate(). An exception with no matching handler also ultimately terminates the program. Exceptions are therefore not an automatic recovery mechanism; they only deliver failure to a boundary that can still apply a policy.

Examples

The next three examples build from typed handling to stack unwinding and then the strong exception guarantee. Each program was compiled with -std=c++23 -Wall -Wextra -Wpedantic -Werror under GCC 13.3.0 and executed; the displayed output is from those runs.

Handle input failures by type

parse_age() distinguishes a format error from a range error. The caller can give the two failures different outcomes while the success path returns only an age.

Both handlers receive their exceptions by const reference. That avoids a copy and preserves the actual exception type and virtual dispatch to what(). This boundary does not need catch (const std::exception&) because it promises to handle only the two known failures.

std::stoi() can itself throw std::invalid_argument or std::out_of_range. The wrapper then checks parsed because std::stoi("42years") accepts the numeric prefix instead of rejecting the trailing characters. The wrapper must complete its own input contract.

Exception types express failure categories that callers can distinguish; the message is diagnostic detail. Program logic should not parse what() text because a standard-library implementation, locale, or later edit can change it.

Observe unwinding and rethrowing

The next program constructs trace objects across three call layers. The service layer logs the exception and uses a bare throw;, so the outer layer still receives the original std::runtime_error.

#include <iostream>
#include <stdexcept>
#include <string>
#include <utility>

class Trace {
public:
    explicit Trace(std::string name) : name_(std::move(name)) {
        std::cout << "acquire " << name_ << '\n';
    }

    ~Trace() {
        std::cout << "release " << name_ << '\n';
    }

private:
    std::string name_;
};

void read_response() {
    Trace response("response");
    throw std::runtime_error("checksum mismatch");
}

void load_order() {
    Trace transaction("transaction");
    try {
        read_response();
    } catch (const std::exception& error) {
        std::cout << "service logged: " << error.what() << '\n';
        throw;
    }
}

int main() {
    Trace request("request");
    try {
        load_order();
    } catch (const std::runtime_error& error) {
        std::cout << "main caught: " << error.what() << '\n';
    }
}

acquire request
acquire transaction
acquire response
release response
service logged: checksum mismatch
release transaction
main caught: checksum mismatch
release request

response is destroyed before control enters the handler in load_order(). While that handler runs, transaction remains in scope; it is destroyed only after the bare throw; exits the handler. request is outside main()’s try, so it lives until main() finishes normally.

This order shows that a handler has an ordinary scope and local lifetime too. Logging code can read context that remains alive, but it must not retain references to objects that the rethrow is about to destroy. Copy stable data or construct a new exception with context when that information must survive another layer.

Writing throw error; instead of throw; constructs a new object from an expression whose static type is std::exception, causing object slicing . A bare rethrow preserves the current exception object and its dynamic type.

Commit before changing visible state

Ledger::append_batch() first validates and appends into a temporary copy, then swaps that copy into the member only after all work succeeds. A rejected batch does not change the ledger visible before the call.

#include <iostream>
#include <stdexcept>
#include <vector>

class Ledger {
public:
    Ledger() : entries_{100} {}

    void append_batch(const std::vector<int>& amounts) {
        auto next = entries_;
        for (int amount : amounts) {
            if (amount < 0) {
                throw std::invalid_argument("amount must be non-negative");
            }
            next.push_back(amount);
        }
        entries_.swap(next);
    }

    void print() const {
        std::cout << "ledger:";
        for (int amount : entries_) {
            std::cout << ' ' << amount;
        }
        std::cout << '\n';
    }

private:
    std::vector<int> entries_;
};

int main() {
    Ledger ledger;
    try {
        ledger.append_batch({20, -5, 30});
    } catch (const std::invalid_argument& error) {
        std::cout << "rejected: " << error.what() << '\n';
    }
    ledger.print();

    ledger.append_batch({20, 30});
    ledger.print();
}

rejected: amount must be non-negative
ledger: 100
ledger: 100 20 30

The first call fails after 20 has already been appended to the temporary vector. Unwinding destroys the temporary, while the member entries_ still contains only 100. The second call completes every potentially failing construction and append before it performs the non-throwing vector::swap().

This prepare-then-commit structure implements the strong exception guarantee. Its costs include copying the existing vector and holding extra storage, so it is not a mechanical recipe. Another design could fully validate the input and then mutate directly, but allocation and every other failure point would still need analysis.

Exception safety describes observable state after failure, not the presence of a try. You can prove a guarantee only by listing each potentially throwing operation and the state changes already committed before it.

Pitfalls

Throwing pointers or catching by value

Fix: throw a complete object by value and catch it by const reference. Custom exceptions normally derive from std::runtime_error or another suitable standard exception so that what() and polymorphic handling work naturally; do not make a handler guess who releases an exception pointer.

Swallowing a failure at the wrong layer

Fix: catch only at a boundary that can recover, translate the failure into an interface result, or end a defined unit of work. Use a bare throw; when logging before propagation; when translating, retain the original context and make clear that the operation still failed.

Fighting non-local control flow with manual cleanup

Fix: give the resource to an RAII type immediately after acquisition, such as std::unique_ptr, a container, a stream, or a lock guard. A destructor must perform infallible local cleanup; a close operation that needs to report failure can be a separate explicit member function.

Validating after half the mutation

Fix: validate every condition that can be checked before mutation, do potentially failing work in temporary state, and commit with a non-throwing operation. If cost or domain rules permit only the basic guarantee, document which state remains valid and which values can change after failure.

Making a false noexcept promise

Fix: inspect exception specifications across the complete call path and use std::is_nothrow_* traits to verify generic operations. Remove the declaration when non-throwing behavior cannot be proved; if a cleanup path must absorb errors, catch internally and report through a channel that cannot throw again.

Driving ordinary loops with exceptions

Fix: use iterator bounds, a Boolean, std::optional, std::expected, or an error code for expected outcomes. Throw only when an operation cannot keep its promise and the handling policy belongs to an outer layer; choose by semantics, not an unmeasured performance slogan.

Further reading

• C++23 working draft: exception handling
• C++23 working draft: handling an exception
• C++23 working draft: constructors and destructors
• C++23 working draft: exception specifications
• C++ Core Guidelines: error handling