Exception Handling in C++

Exception handling in C++ is a structured mechanism for detecting, signalling, and recovering from error conditions that cannot (or should not) be handled locally. It separates the code that detects an error from the code that handles it, without requiring every intermediate function to check and forward error codes.

The three keywords involved are try, throw, and catch.

Why it matters:

1. Separation of concerns: Normal logic and error-recovery logic are in distinct blocks, making code easier to read and maintain.

2. Propagation without boilerplate: An exception thrown deep in a call stack automatically propagates upward through every intermediate function until a matching catch is found — no manual error-code forwarding required.

3. RAII integration: C++ exception handling works hand-in-hand with destructors. When a stack unwinds due to an exception, all local objects with destructors are destroyed in reverse construction order. This guarantees that std::unique_ptr, std::lock_guard, file handles, and other RAII wrappers release their resources even on the exception path — this is one of the most important safety properties of C++.

4. Type-safe error signalling: Exceptions carry typed objects, allowing different catch handlers to respond to different error categories.

When not to use exceptions:

• Performance-critical hot paths: Exception handling has near-zero overhead when no exception is thrown (zero-cost exceptions with modern ABIs), but throwing and catching is expensive. Do not use exceptions for expected control flow.
• Embedded/real-time systems: Many such environments disable exceptions entirely (-fno-exceptions); use error codes or std::expected (C++23) instead.
• noexcept functions: Mark functions that genuinely cannot throw as noexcept — this enables compiler optimizations and communicates intent clearly. Destructors are implicitly noexcept.

Modern practice (C++23): std::expected provides an alternative for functions that want to return either a value or an error without using exceptions, similar to Rust's Result.

In C++, the try-catch block separates code that may throw an exception from the code that handles it. Code inside the try block executes normally; if any statement throws, execution jumps immediately to the matching catch block and the rest of the try block is skipped.

Basic example:

#include 
#include 

double divide(double a, double b) {
    if (b == 0.0)
        throw std::invalid_argument("division by zero");
    return a / b;
}

int main() {
    try {
        double result = divide(10.0, 0.0);
        std::cout << "Result: " << result << '\n';  // skipped
    }
    catch (const std::invalid_argument& e) {
        std::cerr << "Error: " << e.what() << '\n';
    }
}

Multiple catch blocks — ordered from most specific to most general:

try {
    riskyOperation();
}
catch (const std::out_of_range& e) {
    std::cerr << "Range error: " << e.what() << '\n';
}
catch (const std::runtime_error& e) {
    std::cerr << "Runtime error: " << e.what() << '\n';
}
catch (const std::exception& e) {
    std::cerr << "Unexpected error: " << e.what() << '\n';
}
catch (...) {
    // catch-all for non-std exceptions (e.g., thrown integers)
    std::cerr << "Unknown exception\n";
}

Important rules:

• Always catch exceptions by const reference (const std::exception&), not by value. Catching by value slices derived exception objects and copies unnecessarily.
• The catch(...) handler catches anything, including non-class types. It is typically used as a last resort or in destructors to prevent exceptions from escaping.
• Stack unwinding: when an exception propagates, all local variables between the throw site and the matching catch are destroyed in reverse order — RAII handles resource cleanup automatically.
• A try block can be nested; the inner catch has the first opportunity to handle the exception, and can rethrow with a bare throw; to pass it to an outer handler.

noexcept and termination: if an exception propagates out of a noexcept function, std::terminate is called immediately — there is no further stack unwinding. This is why destructors are noexcept by default.

The throw keyword is used to signal that an exceptional condition has occurred. It immediately transfers control out of the current function, unwinding the call stack until a matching catch block is found.

Throwing a standard exception:

#include 

void setAge(int age) {
    if (age < 0 || age > 150)
        throw std::out_of_range("Age must be between 0 and 150");
}

Throwing any type — you can throw any copyable type, but throwing objects derived from std::exception is strongly preferred because it integrates with standard catch handlers:

throw 42;              // legal but poor practice
throw "error";         // legal but poor practice
throw std::runtime_error("something went wrong");  // idiomatic

Rethrowing — inside a catch block, a bare throw; with no operand rethrows the current exception object without slicing it:

catch (const std::exception& e) {
    log(e.what());
    throw;  // propagate the original exception unchanged
}

throw in expressions vs. throw as a statement:

Since C++11, throw can appear as an expression (yielding type void), which enables patterns like:

int value = (ptr != nullptr) ? *ptr : throw std::runtime_error("null ptr");

What happens after throw:

1. The thrown object is copy- or move-constructed into a special storage area (exception object).
2. The runtime begins stack unwinding — destructors of all local objects between the throw site and the matching catch are called in reverse construction order.
3. The first catch block whose parameter type matches the exception type (or a base class of it) takes control.
4. If no matching catch is found anywhere on the call stack, std::terminate is called.

noexcept interaction: throwing from a function declared noexcept calls std::terminate directly — stack unwinding does not occur. This is intentional: noexcept functions make a hard contract that no exception will escape.

The standard exception library, defined in and, provides a hierarchy of pre-built exception classes that cover the most common runtime error categories. Using these classes (rather than throwing raw integers or strings) gives every caller a uniform interface for inspecting exceptions.

The hierarchy (rooted in ``):

std::exception
├── std::logic_error        — errors detectable before runtime (bad arguments, precondition violations)
│   ├── std::invalid_argument
│   ├── std::domain_error
│   ├── std::length_error
│   └── std::out_of_range
└── std::runtime_error      — errors only detectable at runtime
    ├── std::range_error
    ├── std::overflow_error
    ├── std::underflow_error
    └── std::system_error   (C++11 — wraps OS/library error codes)
        └── std::ios_base::failure

There are also library-specific exceptions not in this tree: std::bad_alloc (thrown by new), std::bad_cast (thrown by dynamic_cast), std::bad_optional_access (C++17), and others.

Why use standard exceptions:

1. Common interface: all derive from std::exception, so a single catch (const std::exception& e) handler can catch everything and call e.what() to get a description.
2. Semantic clarity: std::out_of_range immediately communicates a bounds problem; std::invalid_argument communicates a bad input — no comment needed.
3. Interoperability: third-party libraries and the standard library itself throw from this hierarchy, so your catch handlers work uniformly.

Extending the hierarchy — the idiomatic way to define application-specific exceptions:

class DatabaseError : public std::runtime_error {
public:
    explicit DatabaseError(const std::string& msg)
        : std::runtime_error(msg) {}
};

// Caught by either:
catch (const DatabaseError& e) { /* specific */ }
catch (const std::runtime_error& e) { /* general */ }
catch (const std::exception& e) { /* catch-all std */ }

C++23 note: std::expected complements the exception library for situations where error handling should be explicit and non-throwing, similar to Rust's Result type.

Exception propagation is the automatic process by which an unhandled exception travels up the call stack from the point where it was thrown until a matching catch block is found.

How it works:

1. A throw expression is evaluated — the exception object is constructed and stored in special storage managed by the runtime.
2. The current function exits immediately (without executing any remaining statements).
3. The runtime unwinds the stack: for every stack frame exited, destructors of all local objects in that frame are called in reverse construction order (this is RAII at work).
4. At each frame, the runtime checks whether that function's call site is inside a try block with a matching catch.
5. If a match is found, control transfers to that catch block.
6. If no matching catch is found anywhere on the stack, std::terminate is called and the program ends.

Example showing propagation through multiple frames:

void c() {
    throw std::runtime_error("error in c");
}

void b() {
    c();  // exception propagates through here
}

void a() {
    try {
        b();  // exception propagates through here
    }
    catch (const std::runtime_error& e) {
        std::cerr << "Caught in a: " << e.what() << '\n';
    }
}

c() throws, exits, b() exits (its locals are destroyed), and a()'s try block catches the exception. Neither b() nor c() needed any error-handling code.

Rethrowing during propagation:

A catch block can rethrow the current exception with a bare throw; — this propagates the original exception object (including its dynamic type) without slicing:

catch (const std::exception& e) {
    log(e.what());
    throw;  // continue propagating
}

Writing throw e; instead would slice the exception to std::exception — always prefer bare throw; to rethrow.

noexcept and propagation: if an exception propagates into a function declared noexcept, std::terminate is called immediately and the rest of the stack is not unwound. Destructors are implicitly noexcept for this reason — an exception escaping a destructor during stack unwinding would call std::terminate.

std::current_exception / std::rethrow_exception (C++11): these allow capturing an in-flight exception as a std::exception_ptr and rethrowing it later, enabling exception transport across threads (e.g., std::future uses this internally).