Why should you always catch exceptions by const reference rather than by value or pointer?

Catching by **const reference (`const std::exception&`)** preserves polymorphism (allowing `e.what()` and derived methods to dispatch dynamically via the vtable) and prevents **object slicing** (which occurs when copying into a base class by value). Catching by pointer requires throwing a raw `new` pointer, which forces the handler to remember to call `delete`, risking memory leaks.

How do modern C++ compilers achieve 'Zero-Cost' exceptions on the happy path?

Compilers generate static tables in the **`.eh_frame`** (DWARF) or SEH metadata sections mapping ranges of instruction pointers to landing pads and cleanup routines. When no exception is thrown, entering and exiting `try` blocks executes no extra instructions. Overhead only occurs during an actual `throw`, where the OS/runtime searches the tables and unwinds stack registers.

When should you use std::expected instead of throwing exceptions?

Use **`std::expected `** for **expected domain conditions and hot-path operations** (e.g. input validation, network timeouts, cache misses, parsing) where failures occur frequently and the cost of stack unwinding (thousands of cycles) cannot be tolerated. Reserve C++ exceptions for **truly exceptional, rare failures** (e.g. out of memory, hardware faults, broken systemic invariants) where the happy path must have zero branch overhead.

"Why did C++11 make all destructors implicitly `noexcept(true)`? What exact runtime sequence occurs if an exception escapes from a destructor during stack unwinding?"

1. **Active In-Flight Exception**: When an initial exception is thrown, the C++ runtime personality routine searches the call stack and begins Phase 2 (stack unwinding). It pops stack frames and invokes destructors for all live local automatic objects. At this point, exactly one uncaught exception is active (`std::uncaught_exceptions() >= 1`). 2. **The Second In-Flight Exception**: If a destructor executing during unwinding throws an exception that escapes its body, there are now **two simultaneously active in-flight exceptions** in the same thread. 3. **No Resolution Mechanism**: The C++ exception handling model has no mechanism to combine two exceptions or arbitrarily discard one. The ISO C++ standard explicitly mandates that the runtime immediately invoke **`std::terminate()`**, aborting the entire process without unwinding any remaining frames or running further destructors. 4. **Implicit `noexcept` Contract**: C++11 formalized this invariant by making all user-defined and compiler-generated destructors implicitly `noexcept(true)`. Even if no unwinding is in progress, an unhandled exception escaping a destructor calls `std::terminate()`. All destructor cleanups must swallow errors internally (e.g. via `try/catch` or logging).

"You implemented a custom move constructor for your class, but profiler traces show that `std::vector::push_back` and `reserve` still call the copy constructor during capacity doubling! Why does `std::vector` refuse to use your move constructor, and how does `std::move_if_noexcept` work?"

1. **The Strong Exception Safety Guarantee**: Standard containers guarantee that if an operation fails (e.g. `std::bad_alloc` or an element constructor throws), the container's state remains exactly as it was before the function call (commit-or-rollback). 2. **The Irreversible Move Problem**: Suppose `std::vector` is resizing from capacity 4 to 8. It allocates a new 8-element buffer and moves elements 0, 1, and 2 from the old buffer to the new buffer using move constructors. Now, element 3's move constructor throws an exception! The new buffer cannot be committed. But elements 0, 1, and 2 in the old buffer are already hollowed out (`nullptr` / moved-from zombies). They cannot be safely restored! The original container is irrevocably corrupted. 3. **Defensive Copying**: If `std::vector` copies instead of moves, the elements in the old buffer remain 100% pristine. If copying throws on element 3, the vector simply destroys elements 0..2 in the new buffer, frees the new memory, and rethrows—leaving the original vector completely unharmed. 4. **`std::move_if_noexcept`**: The standard library uses `std::move_if_noexcept(el)`. If `std::is_nothrow_move_constructible_v ` is false, it returns `const T&` (triggering a deep copy) unless `T` is move-only (cannot be copied).

"What happens if an exception is thrown in the middle of a constructor body? Does the object's destructor execute? What happens to members that were already initialized, and how do you prevent memory leaks?"

1. **Object Lifetime Milestone**: In C++, an object's lifetime formally begins **only when its constructor reaches the closing brace `}`**. 2. **Destructor is Never Called**: Because the object was never fully constructed, the runtime **never invokes `~MyClass()`**. 3. **Automatic Subobject Cleanup**: However, the language runtime guarantees that all base class subobjects and data members that were successfully initialized prior to the point of the throw **are destroyed in reverse order of construction**. 4. **The Raw Pointer Leak Hazard**: If the constructor wrote `rawPtr_ = new int[100];` and then threw on the next line, `rawPtr_` is a primitive pointer with no destructor. Because `~MyClass()` never runs, `delete[] rawPtr_` is never executed, and that heap memory is permanently leaked! 5. **Production Solution**: Always use RAII member fields (`std::unique_ptr `, `std::vector`, `std::string`) or function-try-blocks. When a throw occurs, `std::unique_ptr`'s destructor executes automatically during subobject rollback.

"Why is catching exceptions by value `catch (BaseException e)` a critical bug in production systems, while `catch (const BaseException& e)` is the required standard? Explain object slicing and vtable degradation."

1. **Object Slicing**: When an exception of derived type `CustomHttpException` is thrown, catching it by value `catch (std::exception e)` invokes the copy constructor of `std::exception` using the base subobject of `CustomHttpException`. All derived member variables (`http_status_code`, `request_id`, `url`) are physically sliced off and discarded. 2. **Vtable Reset**: The sliced object `e` in the catch handler has its `_vptr` set to `std::exception::vtable`. When calling `e.what()`, virtual dispatch calls `std::exception::what()`, completely hiding any custom diagnostic strings provided by the derived exception! 3. **Rethrow Degradation**: If the handler tries to rethrow via `throw e;`, it throws the sliced `std::exception` copy, permanently hiding the original derived exception from all outer catch blocks. (Writing `throw;` preserves the original in-flight exception). 4. **Reference Solution**: `catch (const std::exception& e)` passes an 8-byte reference pointing directly to the active exception object in emergency runtime memory with zero copying, zero slicing, and full dynamic polymorphic virtual dispatch.

M2.5

Exception Handling, Stack Unwinding & noexcept Guarantees

Q: What is stack unwinding, and what guarantees does C++ provide during it?

**Stack unwinding** is the process by which the C++ runtime traverses active activation records (stack frames) between the `throw` statement and the matching `catch` handler. The language guarantees that destructors for all fully constructed automatic/local objects within those scopes are called in strict reverse order of construction (LIFO). Unwinding guarantees zero memory or resource leaks for RAII-wrapped resources.

Q: What are the 3 levels of exception safety defined by Dave Abrahams?

1. **Basic Guarantee**: No resources are leaked, and all objects remain in a valid, invariants-preserving state (even if altered). 2. **Strong Guarantee (Commit-or-Rollback)**: The operation either succeeds completely or has no effect (program state remains identical to before the call). 3. **Nothrow / No-fail Guarantee (`noexcept`)**: The function promises never to emit an exception and will always succeed.

Medium High-frequency interview topic Pro OnlyStack UnwindingDestructor Throw CrashBasic / Strong / No-thrownoexceptstd::expected

Short on time? Jump to M2.5 in 1-Day Crash Revision (5 min) →

⚡ 15-Second Mental ModelM2.5 · Instant Intuition

Single-Read Mastery

The Real-World Physical Analogy (Core Intuition)

In modern C++, we never guess what the compiler does. We look directly at byte offsets, CPU registers, and object ownership lifetimes.

Rule to Remember: Make illegal states impossible to compile or run.

3 Golden Facts to Remember

Fact #1

What is stack unwinding, and what guarantees does C++ provide during it?

Stack unwinding is the process by which the C++ runtime traverses active activation records (stack frames) between the throw statement and the matching catch handler. The language guarantees that destructors for all fully constructed automatic/local objects within those scopes are called in strict reverse order of construction (LIFO). Unwinding guarantees zero memory or resource leaks for RAII-wrapped resources.

Fact #2

Why does throwing an exception from a destructor terminate the program?

If a destructor throws an exception while stack unwinding is already in progress, there would be two simultaneously active, in-flight exceptions. The C++ language runtime has no mechanism to merge or decide which exception to handle, so the standard specifies that the runtime must immediately invoke std::terminate(), terminating the application without further cleanup.

Fact #3

What are the 3 levels of exception safety defined by Dave Abrahams?

Basic Guarantee: No resources are leaked, and all objects remain in a valid, invariants-preserving state (even if altered).
Strong Guarantee (Commit-or-Rollback): The operation either succeeds completely or has no effect (program state remains identical to before the call).
Nothrow / No-fail Guarantee (noexcept): The function promises never to emit an exception and will always succeed.

Interviewer's lens

What separates a strong C++ candidate from a textbook answer

Think of C++ exceptions like a skyscraper fire escape system: as long as there is no fire, walking the hallways costs zero extra energy (zero CPU cycles). But when an alarm sounds, the system automatically closes fire doors and evacuates floors in reverse order (LIFO). If an evacuation door itself jams and blows up (throwing from a destructor), the entire building instantly collapses (std::terminate).

Interviewers use exception handling to separate junior programmers who sprinkle try/catch (...) randomly from engineers who write crash-proof production code. Weak candidates catch exceptions by value (causing object slicing) or throw inside destructors. Senior engineers master four non-negotiable principles:

Table-Driven Zero-Cost Model: Normal execution through try blocks incurs 0 runtime CPU cycles because unwinding tables (.eh_frame) sit out-of-band in read-only binary space.
Deterministic Stack Unwinding: The runtime pops activation frames and runs destructors in strict LIFO order, guaranteeing leak-free RAII cleanup.
Destructor Invariants: Destructors are implicitly noexcept. Throwing while unwinding triggers two simultaneous in-flight exceptions, causing immediate std::terminate() abort.
The Strong Guarantee & C++23 std::expected: Using commit-or-rollback staging for mutations, and switching to C++23 std::expected for high-frequency domain errors on performance-critical paths.

Under the hood & memory layout

Hardware & memory representation

Modern 64-bit systems use a table-driven 'Zero-Cost' exception model (DWARF .eh_frame on Linux, SEH on Windows). On the happy path where no error occurs, entering and exiting try blocks executes zero extra CPU instructions.

When a throw executes, the runtime takes over through a deterministic 3-phase sequence:

Phase 1 (Search Phase): The runtime personality routine looks up the CPU instruction pointer (RIP) in the binary's metadata tables, searching up the call stack for an enclosing catch block that matches the exception type.
Phase 2 (Stack Unwinding & LIFO Cleanup): The runtime systematically rewinds activation frames, restoring CPU registers and calling destructors for all fully constructed local RAII objects in strict reverse order of construction (LIFO).
Phase 3 (The Double-Fault Panic): If a destructor running during stack unwinding throws a second unhandled exception, the C++ runtime detects two simultaneous in-flight exceptions. Because recovery is impossible, it calls std::terminate() immediately, aborting the process without further cleanup.

.eh_frame Section

Read-only ELF metadata mapping instruction pointer (RIP) ranges to Call Frame Information (CFI) and landing pad addresses. Consumes binary disk size but zero runtime CPU cycles on the happy path.

Exception Object Header

Allocated by the runtime on a thread-local or emergency heap chunk (managed by __cxa_allocate_exception). Lives outside the normal stack frame so it survives stack unwinding.

Polymorphic Catch Reference

Catching by const std::exception& passes an 8-byte vptr-aware reference to the active exception object. Catching by value (catch (std::exception e)) copies only the base subobject, slicing away custom derived members and vtable.

noexcept Operator & ABI

noexcept functions omit stack unwinding cleanup tables. If an exception escapes a noexcept function, the runtime invokes std::terminate() immediately without unwinding parent frames.

Core concepts & syntax traps

Stack Unwinding & Table-Driven Exception Mechanics

When an exception is thrown, C++ switches from normal code execution to runtime stack unwinding.

Zero-Cost Happy Path: The compiler generates read-only .eh_frame metadata mapping instruction ranges to cleanup landing pads. In the absence of exceptions, this incurs 0 CPU cycle overhead.
LIFO Destructor Cascade: During an active throw, the runtime rewinds stack frames and executes destructors for every local object in exact reverse order of construction.
Guaranteed RAII Reclamation: Mutex locks (std::lock_guard), file handles, and memory buffers (std::unique_ptr) are deterministically freed, eliminating leaks even across deep call hierarchies.

C++23 snippet

void level2() {
    std::unique_ptr<File> f = openFile("data.txt");
    std::lock_guard<std::mutex> lock(mtx);
    throw std::runtime_error("disk error");
    // When throw occurs, stack unwinding runs ~lock_guard() first, then ~unique_ptr()!
}

Interview takeaway:

RAII is the bedrock of C++ exception safety: stack unwinding guarantees deterministic cleanup of every local object.

Why Throwing From a Destructor Triggers std::terminate()

Since C++11, all destructors are implicitly marked noexcept(true).

Here is why throwing from a destructor is fatal:

Active Unwinding: Suppose an exception is already traveling up the stack, causing local destructors to run.
The Second Exception: If one of those destructors throws an exception, there are now two independent exceptions active at the same instant.
Immediate Process Death: C++ cannot propagate two exceptions simultaneously. The runtime immediately invokes std::terminate(), aborting the program on the spot without running any remaining cleanups. Always handle and swallow errors internally inside destructors.

C++23 snippet

struct Dangerous {
    ~Dangerous() { // implicitly noexcept(true)
        throw std::runtime_error("error in dtor!"); // If unwinding is active: CRASH via std::terminate!
    }
};

struct SafeDestructor {
    ~SafeDestructor() noexcept {
        try {
            flushBuffer();
        } catch (...) {
            // Swallow or log error; NEVER let exceptions escape a destructor!
        }
    }
};

Interview takeaway:

Never allow an exception to escape from a destructor; doing so during stack unwinding triggers an immediate crash.

Catching by const std::exception& vs The Object Slicing Trap

Catching exceptions requires deliberate reference hygiene.

The Object Slicing Trap: Catching by value (catch (std::exception e)) copies the thrown derived exception into a base object. This slices away all derived member fields and resets the virtual table pointer to base, so e.what() loses specific derived diagnostic details.
Polymorphic Reference (Best Practice): Catching by const std::exception& avoids any copy overhead and preserves full polymorphic behavior and derived methods through the vtable.
The Raw Pointer Anti-Pattern: Throwing heap pointers (throw new Exception()) forces the catch handler to call delete. If any intermediate handler rethrows or misses it, memory is permanently leaked.

C++23 snippet

class HttpError : public std::runtime_error {
    int statusCode_;
public:
    HttpError(int code, const std::string& msg) : std::runtime_error(msg), statusCode_(code) {}
    int code() const { return statusCode_; }
};

// BAD: Object slicing! Discards 'statusCode_' and HttpError vtable
// catch (std::runtime_error err) { ... }

// GOOD: Polymorphic catch preserves dynamic type and custom methods
catch (const HttpError& err) {
    std::println("HTTP status: {}", err.code());
}

Interview takeaway:

Always catch exceptions by const reference (const std::exception&) to prevent object slicing and avoid copies.

The 3 Abrahams Exception Safety Guarantees

Established by Dave Abrahams, every C++ operation must satisfy one of three formal exception safety levels:

Basic Guarantee: If an exception occurs, no resources (memory, file handles, locks) are leaked, and all objects remain in a valid, usable (though possibly modified) state.
Strong Guarantee (Commit-or-Rollback): The operation is atomic: it either succeeds completely, or rolls back state as if it was never called.
Nothrow Guarantee (noexcept): The function promises never to emit an exception under any circumstance. Mandatory for destructors, move constructors, and swap functions.

C++23 snippet

// Strong Exception Guarantee pattern (Copy & Staging):
void updateConfig(const Config& newCfg) {
    Config staged = newCfg;      // May throw during allocation
    staged.validate();           // May throw validation error
    // Commit point: swap cannot throw!
    std::swap(currentConfig_, staged); 
}

Interview takeaway:

Design mutating operations with the Strong Guarantee (commit-or-rollback) by staging modifications before committing.

C++23 std::expected<T, E> vs Exceptions for Hot Paths

While table-driven exceptions are zero-cost on the happy path, throwing an exception is very expensive—often costing thousands of CPU cycles to parse metadata tables and restore registers.

When Exceptions Fit: Use C++ exceptions for truly rare, abnormal systemic failures (hardware failure, disk full, corrupted database).
When C++23 std::expected Fits: For expected operational outcomes on latency-critical hot paths (invalid user input, cache misses, network timeouts), use std::expected<T, E>.
Inline Monadic Storage: std::expected stores either a value or an error inline on the stack with zero dynamic heap allocation, zero stack unwinding overhead, and clean monadic chaining (.and_then(), .or_else()).

C++23 snippet

#include <expected>

enum class ParseError { InvalidChar, Overflow };

std::expected<int, ParseError> parsePort(std::string_view str) noexcept {
    if (str.empty()) return std::unexpected(ParseError::InvalidChar);
    // ... parsing logic ...
    return 8080;
}

auto result = parsePort("8080");
if (result) {
    std::println("Port: {}", *result);
} else {
    std::println("Parse failed!");
}

Interview takeaway:

Use exceptions for rare exceptional errors; use C++23 std::expected for expected domain errors on latency-sensitive hot paths.

Brute2Best Pro Content

Unlock Live Implementation & Interview Scenarios

The C++23 production code, live coding steps, scenario twist solutions, and common UB traps are part of Brute2Best Pro. Module 1 is completely free.

All 440 visual dry runs & algorithms

Interactive step-by-step playback with pointer & array state transitions

52 comprehensive LLD chapters

Interactive UML diagrams, real-world stories (Food Delivery, Trading, RPG), and practice solutions

40 C++ basics labs & hardware memory models

Vtables, byte layouts, assembly insights, and multi-threading race conditions

Production-ready C++23 source code

Modern idioms, clean contracts, time/space complexity derivations, and interview takeaways

Create Free Account Log in

First anchor question per pattern, Part 1 LLD & Module 1 C++ basics are 100% Free forever.

Next In Your Mastery Journey

Apply C++ Internals to LLD & Algorithmic Patterns

Full-stack systems engineering

LLD Architecture

52 Low-Level Design (LLD) Chapters in C++23

Apply modern C++ concepts to production architectures, UML models, and machine coding.

Explore Track

DSA Patterns

DSA Patterns: From Brute Force to Optimal

Master algorithmic step-by-step derivations with interactive dry runs.

Explore Track

M2.4 · Copy Elision (RVO / NRVO) & Object Lifetime Traps M3.1 · The 4 Pillars of OOP in Production C++