{"title":"Exception Basics","description":null,"content":"An exception is an abnormal condition that interrupts the normal flow of a program: a product not found, an order total that overflows, a payment record that can't be loaded. C++ gives you a dedicated mechanism for signalling these conditions and handling them somewhere up the call stack, separate from the values your functions return. This lesson covers what exceptions are, why they exist, and the high-level shape of how they work. Later lessons in this section dig into the syntax, the standard exception hierarchy, custom exception classes, and the runtime mechanics.\n\n---\n\n# What an Exception Actually Is\n\nAn exception is a value (usually an object) that your code creates to say \"something has gone wrong, and I can't continue from here.\" Once that value is created, normal execution stops at that point. The program walks back up the chain of function calls looking for code that knows how to handle this kind of problem. When it finds one, control jumps there. If it doesn't find one, the program terminates.\n\nThat's it. An exception is a typed value plus a control-flow jump, both bundled into a single language feature.\n\nThink about ordering something from an online store. You add three items to your cart, click \"Place order\", and the system tries to charge your card. If the card is declined, the order can't be completed. The checkout function doesn't know whether you want to retry, switch to a different card, save the cart for later, or cancel. That's a decision for code higher up, closer to the user. The checkout function's job is to report the failure clearly, not to guess what should happen next.\n\nExceptions are the C++ way to report that kind of failure across function boundaries without baking the recovery policy into low-level code.\n\n\n```cpp\n#include \n#include \n\ndouble applyDiscount(double price, double percent) {\n if (percent < 0.0 || percent > 100.0) {\n throw std::runtime_error(\"discount percent out of range\");\n }\n return price * (1.0 - percent / 100.0);\n}\n\nint main() {\n try {\n double finalPrice = applyDiscount(49.99, 150.0);\n std::cout << \"Final price: $\" << finalPrice << std::endl;\n } catch (const std::exception& e) {\n std::cout << \"Could not apply discount: \" << e.what() << std::endl;\n }\n return 0;\n}\n```\n\n\nThree pieces are doing real work in that program. The `throw` creates a `std::runtime_error` object and stops `applyDiscount` from returning a meaningless price. The `try` block marks the region of code where we're prepared to handle a failure. The `catch` clause is the handler that takes over when the exception bubbles up. Each piece gets a dedicated lesson in this section.\n\n---\n\n# Why Exceptions Exist\n\nFor a long time, C and early C++ used **error codes** to signal failures. A function returns an integer (or a special value like `nullptr` or `-1`) to indicate what happened, and the caller checks the return value before using any result.\n\nThat works, sort of. The trouble is that nothing forces the caller to check. The compiler is perfectly happy if you ignore the return value and proceed as if nothing went wrong.\n\n**What's wrong with this code?**\n\n\n```cpp\n#include \n#include \n\n// Returns 0 on success, -1 if product not found.\n// On success, writes the price into *outPrice.\nint lookupPrice(const std::string& productId, double* outPrice) {\n if (productId == \"P-1001\") { *outPrice = 29.99; return 0; }\n if (productId == \"P-1002\") { *outPrice = 14.99; return 0; }\n return -1;\n}\n\nint main() {\n double price;\n lookupPrice(\"P-9999\", &price); // ignored return code\n std::cout << \"Subtotal for one unit: $\" << price << std::endl;\n return 0;\n}\n```\n\n\nThe caller never inspected the return value. The product wasn't found, so `lookupPrice` left `price` untouched, and `price` was never initialised. The program reads uninitialised memory and prints whatever happened to be on the stack. The compiler issues at most a warning, and many real codebases ship code shaped exactly like this.\n\n**Fix using exceptions:**\n\n\n```cpp\n#include \n#include \n#include \n\ndouble lookupPrice(const std::string& productId) {\n if (productId == \"P-1001\") return 29.99;\n if (productId == \"P-1002\") return 14.99;\n throw std::runtime_error(\"product not found: \" + productId);\n}\n\nint main() {\n try {\n double price = lookupPrice(\"P-9999\");\n std::cout << \"Subtotal for one unit: $\" << price << std::endl;\n } catch (const std::exception& e) {\n std::cout << \"Lookup failed: \" << e.what() << std::endl;\n }\n return 0;\n}\n```\n\n\nWith the exception version, there is no way for `main` to keep running with garbage in `price`. If `lookupPrice` throws, control jumps straight to the `catch` block and the bad `price` line never executes. The failure cannot be silently dropped on the floor.\n\n---\n\n# The Cost of Error Codes\n\nThe \"forgot to check\" bug is the most visible problem with error codes, but it's not the only one. There are three patterns that make error codes painful in real codebases.\n\n### Return values get crowded\n\nA function often has one natural return value: the price, the count, the parsed total. Adding an error channel forces you to pick between mixing the value and the status (using sentinels like `-1`) or splitting them across an `out` parameter and a status code. Both are awkward.\n\n\n```cpp\n// Sentinel: returning -1.0 to mean \"not found\" forces callers to know that magic value\ndouble lookupPrice(const std::string& productId);\n\n// Out parameter: caller has to declare a variable, pass a pointer, and check the status\nint lookupPrice(const std::string& productId, double* outPrice);\n```\n\n\nNeither shape is great. Sentinels conflict with legitimate values (what if the price genuinely is `-1.00` as a refund?). Out parameters split the call into two steps and clutter the function signature.\n\nExceptions keep the return type clean. `double lookupPrice(...)` returns a price, full stop. Errors travel through a separate channel.\n\n### Errors propagate badly through nested calls\n\nIn any non-trivial program, function A calls B calls C calls D. If D fails, every function in between has to forward the error code up, checking it and returning it again at each level. The code gets buried in scaffolding.\n\n\n```cpp\nint placeOrder(...) {\n int rc = chargeCard(...);\n if (rc != 0) return rc;\n rc = reserveStock(...);\n if (rc != 0) return rc;\n rc = sendConfirmationEmail(...);\n if (rc != 0) return rc;\n return 0;\n}\n```\n\n\nThe actual work is three lines. The error-forwarding scaffolding is six. With exceptions, the same routine reads like a straight description of the happy path, and the failure handling sits in one place at the boundary where the error can actually be dealt with.\n\n### Cleanup is easy to forget\n\nWhen a function returns early because of an error, every resource it acquired (memory, files, locks) has to be released first. Miss a path and you have a leak. Exceptions, combined with C++'s destructors and RAII, handle this automatically: when control leaves a scope (whether by return, by throw, or by reaching the end), every local object's destructor runs.\n\n\n> **INFO**\n>\n> **Cost note:** Exceptions are not free, but they are **cheap on the happy path** and **expensive on the throw path**. We come back to this in a later section.\n\n\n---\n\n# Runtime Errors vs Logic Errors\n\nWhen you start writing code that throws exceptions, it helps to distinguish two broad categories of \"things that went wrong.\" The standard library actually uses this split when it organises its built-in exception types, but the categories are useful even before you know the type hierarchy.\n\n**Logic errors** are bugs. They represent situations the programmer should have prevented: an index out of bounds, a null pointer dereferenced, an invariant violated. In principle, you could have caught these by reading the code carefully. They indicate a defect in the program, not a problem with the outside world.\n\nExamples in an e-commerce setting:\n\n- Adding a product with a negative price because of a sign mistake in the input parser.\n- Indexing past the end of a cart array.\n- Constructing an `Order` object with an empty customer ID.\n\n**Runtime errors** are conditions that depend on the world outside the program. The code itself may be correct, but something external didn't cooperate: the database is unreachable, the user typed a malformed address, the file disappeared between checks. No amount of code review can rule these out, because they're not bugs.\n\nExamples in the same setting:\n\n- A product lookup fails because the product was deleted by an admin five minutes ago.\n- A payment provider rejects the card.\n- The inventory file is corrupted and won't parse.\n\n\n```mermaid\nflowchart TD\n ERR[Something went wrong]:::primary\n\n LOGIC[Logic error
Bug in the program]:::orange\n RUNTIME[Runtime error
External condition]:::cyan\n\n L1[Out-of-range index]:::secondary\n L2[Invalid argument]:::secondary\n L3[Broken invariant]:::secondary\n\n R1[Product not found]:::teal\n R2[Payment declined]:::teal\n R3[File unreadable]:::teal\n\n ERR --> LOGIC\n ERR --> RUNTIME\n\n LOGIC --> L1\n LOGIC --> L2\n LOGIC --> L3\n\n RUNTIME --> R1\n RUNTIME --> R2\n RUNTIME --> R3\n\n classDef primary fill:#00ceff,stroke:#000,color:#000\n classDef secondary fill:#ffa94d,stroke:#000,color:#000\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef teal fill:#38d9a9,stroke:#000,color:#000\n```\n\n\nThe diagram lines up two families of failure. Logic errors say \"the program shouldn't have reached this state.\" Runtime errors say \"the program reached a state it can't handle on its own.\" Both are reported through exceptions, but they call for different responses. Logic errors usually mean fix the code and ship a new build. Runtime errors usually mean surface the problem to the user, try again, fall back to a different path, or roll back.\n\nThe standard library has two corresponding base classes, `std::logic_error` and `std::runtime_error`, both inheriting from `std::exception`. They come with subtypes like `std::invalid_argument`, `std::out_of_range`, and `std::overflow_error`.\n\n---\n\n# Throw, Unwind, Catch (At a Glance)\n\nThe whole exception mechanism in C++ comes down to three steps. The shape is worth seeing now so the rest of this lesson makes sense; the detailed syntax comes in the next lesson.\n\n1. **Throw.** Code creates an exception object and uses `throw` to launch it. Execution of the current function stops at that point. Anything after `throw` in this function is skipped.\n2. **Unwind.** The runtime walks back up the call stack, destroying every local object whose lifetime ends as it leaves each function. This destruction is automatic and runs the proper destructors. The walk continues until it finds a `catch` handler that matches the exception's type.\n3. **Catch.** The matching handler takes over. The exception object is passed into it, and the program resumes execution from inside the handler. After the handler runs, the program continues normally below the corresponding `try` block.\n\n\n```mermaid\nflowchart LR\n A[main calls
placeOrder]:::cyan\n B[placeOrder calls
chargeCard]:::cyan\n C[chargeCard calls
contactBank]:::cyan\n D[contactBank
THROW]:::red\n\n U1[Unwind:
destroy locals in
contactBank]:::orange\n U2[Unwind:
destroy locals in
chargeCard]:::orange\n U3[Unwind:
destroy locals in
placeOrder]:::orange\n\n H[main:
catch handler
runs]:::green\n\n A --> B\n B --> C\n C --> D\n\n D --> U1\n U1 --> U2\n U2 --> U3\n U3 --> H\n\n classDef cyan fill:#00ceff,stroke:#000,color:#000\n classDef red fill:#ff8787,stroke:#000,color:#000\n classDef orange fill:#ffa94d,stroke:#000,color:#000\n classDef green fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe diagram traces one exception's journey. `main` calls `placeOrder`, which calls `chargeCard`, which calls `contactBank`. `contactBank` throws. The runtime then walks back through every function on the way down, cleaning up local objects as it goes, until it finds the `catch` block in `main`. The bank call site, the charge call site, and the place-order call site all get skipped over without any explicit error-handling code at any of those levels.\n\nHere is the same idea in code, kept small on purpose:\n\n\n```cpp\n#include \n#include \n#include \n\nvoid contactBank() {\n throw std::runtime_error(\"bank unreachable\");\n}\n\nvoid chargeCard(const std::string& cardId) {\n std::cout << \"Charging card \" << cardId << std::endl;\n contactBank();\n std::cout << \"Card charged\" << std::endl; // never runs\n}\n\nvoid placeOrder() {\n std::cout << \"Placing order\" << std::endl;\n chargeCard(\"CARD-42\");\n std::cout << \"Order placed\" << std::endl; // never runs\n}\n\nint main() {\n try {\n placeOrder();\n } catch (const std::exception& e) {\n std::cout << \"Order failed: \" << e.what() << std::endl;\n }\n std::cout << \"Program continues normally\" << std::endl;\n return 0;\n}\n```\n\n\nNotice that `\"Card charged\"` and `\"Order placed\"` never print. The exception interrupted both functions on the way up the stack. The handler in `main` runs once, and afterwards the program goes on to its final line.\n\n---\n\n# When to Use Exceptions\n\nExceptions are designed for **exceptional** conditions: states the function meets but can't recover from on its own, that are rare relative to the function's normal use, and that benefit from being reported far up the call chain. Choosing whether to throw is a design decision, and the answer isn't always \"yes.\"\n\nThrow an exception when:\n\n- The function cannot fulfill its contract. `lookupPrice` returns a price; if it can't find one, it can't return anything meaningful, and an exception is appropriate.\n- A precondition was violated and you'd rather surface the problem than silently continue with bad data.\n- The failure is best handled several frames up, not at the call site. A low-level parser doesn't know how to recover from corrupt input; a higher layer might retry, prompt the user, or abort the operation.\n- Resources need to be cleaned up automatically on the failure path, which RAII plus exceptions handle for free.\n\nA small example. The constructor of an `Order` object can't return an error code, because constructors don't return values. If the constructor receives an empty customer ID, throwing is the only sensible way to refuse construction.\n\n\n```cpp\n#include \n#include \n#include \n\nclass Order {\npublic:\n Order(std::string customerId, double total)\n : customerId_(std::move(customerId)), total_(total) {\n if (customerId_.empty()) {\n throw std::runtime_error(\"Order requires a non-empty customer ID\");\n }\n if (total_ < 0.0) {\n throw std::runtime_error(\"Order total cannot be negative\");\n }\n }\n\n void print() const {\n std::cout << \"Order for \" << customerId_\n << \" total $\" << total_ << std::endl;\n }\n\nprivate:\n std::string customerId_;\n double total_;\n};\n\nint main() {\n try {\n Order good(\"CUST-7\", 89.97);\n good.print();\n\n Order bad(\"\", 10.00); // throws\n bad.print(); // never runs\n } catch (const std::exception& e) {\n std::cout << \"Could not create order: \" << e.what() << std::endl;\n }\n return 0;\n}\n```\n\n\nThe constructor rejects invalid input by throwing, and the caller catches the problem at a level where it knows how to react. There's no \"half-constructed\" `Order` floating around. Either the object is fully valid or it doesn't exist at all.\n\n---\n\n# When Not to Use Exceptions\n\nExceptions are a sharp tool, and sharp tools cut the wrong things if you reach for them every time. There are three patterns where exceptions are the wrong answer.\n\n**Don't use exceptions for routine control flow.** If a function has a \"normal\" outcome and a \"not found\" outcome, and both happen all the time, neither is exceptional. Looking up a product by ID in a search bar is a good example. Most user-typed searches won't match anything; that's not a failure, it's just what the function does. Use a return value (`std::optional` is a clean fit) and reserve exceptions for the cases that genuinely interrupt the program's normal operation.\n\n\n```cpp\n#include \n#include \n#include \n\nstd::optional findPrice(const std::string& productId) {\n if (productId == \"P-1001\") return 29.99;\n if (productId == \"P-1002\") return 14.99;\n return std::nullopt;\n}\n\nint main() {\n auto price = findPrice(\"P-9999\");\n if (price) {\n std::cout << \"Price: $\" << *price << std::endl;\n } else {\n std::cout << \"Product not in catalog\" << std::endl;\n }\n return 0;\n}\n```\n\n\nA \"missing product\" here is so routine that throwing would be misleading. `std::optional` describes exactly what the function returns: maybe a price, maybe nothing.\n\n**Don't use exceptions for input validation in tight loops.** If you parse a million product records and a few percent are malformed, treating each malformed record as exceptional means paying the throw cost on every bad row. That's a real performance hit. A return value or a status field on the record is cheaper.\n\n**Don't throw from destructors.** A destructor is called during stack unwinding, and if a second exception is thrown while another one is already in flight, the program calls `std::terminate` and dies. There are advanced techniques to work around this, but the safest rule is: destructors should never throw.\n\n\n> **INFO**\n>\n> **Cost:** On modern compilers, an exception that is never thrown costs essentially nothing on the happy path. A thrown exception is much more expensive than a normal return, often by a factor of 10x to 1000x depending on stack depth and compiler. Use exceptions for the rare path, not the common one.\n\n\n---\n\n# A Slightly Bigger Example\n\nTo pull the pieces together, here is a small e-commerce scenario that uses everything covered so far: a constructor that throws on bad input, a function that throws on a runtime failure, and a single `catch` clause at the top that handles both.\n\n\n```cpp\n#include \n#include \n#include \n#include \n\nclass CartItem {\npublic:\n CartItem(std::string name, double price, int quantity)\n : name_(std::move(name)), price_(price), quantity_(quantity) {\n if (price_ < 0.0) {\n throw std::runtime_error(\"price cannot be negative\");\n }\n if (quantity_ <= 0) {\n throw std::runtime_error(\"quantity must be positive\");\n }\n }\n\n double subtotal() const { return price_ * quantity_; }\n const std::string& name() const { return name_; }\n\nprivate:\n std::string name_;\n double price_;\n int quantity_;\n};\n\ndouble cartTotal(const std::vector& items) {\n if (items.empty()) {\n throw std::runtime_error(\"cart is empty\");\n }\n double sum = 0.0;\n for (const auto& item : items) {\n sum += item.subtotal();\n }\n return sum;\n}\n\nint main() {\n try {\n std::vector cart;\n cart.emplace_back(\"Wireless Headphones\", 79.99, 1);\n cart.emplace_back(\"USB Cable\", 9.99, 2);\n cart.emplace_back(\"Mouse Pad\", 14.99, 1);\n\n std::cout << \"Cart total: $\" << cartTotal(cart) << std::endl;\n\n // This line would throw because quantity is zero:\n cart.emplace_back(\"Pencil\", 1.99, 0);\n\n std::cout << \"Updated cart total: $\" << cartTotal(cart) << std::endl;\n } catch (const std::exception& e) {\n std::cout << \"Cart error: \" << e.what() << std::endl;\n }\n return 0;\n}\n```\n\n\nThe first cart total prints normally. The second `emplace_back` throws inside the `CartItem` constructor, the exception travels up through `emplace_back` and out of the `try` block, the partially-built cart's local objects get cleaned up automatically, and the handler in `main` reports the problem. The \"Updated cart total\" line never runs. The program doesn't crash, and it doesn't continue with bad data either.\n\nThis is roughly the shape most exception-using code takes: low-level functions throw when they meet a state they can't handle, a few outer layers wrap their work in a `try` block, and a single `catch` reports the failure to the right audience.\n\n---\n\n# What's Coming in This Section\n\nThis lesson is the high-level overview. The rest of the section fills in the mechanics.\n\n\n| Lesson | Topic |\n|--------|-------|\n| try, catch & throw | `try`, `catch`, and `throw` syntax in detail |\n| Multiple Catch Blocks | Multiple `catch` handlers, `catch(...)`, and how matching works |\n| Standard Exceptions | The `std::exception` hierarchy: `runtime_error`, `logic_error`, and friends |\n| Custom Exception Classes | Defining your own exception classes |\n| noexcept Specification | `noexcept` and why marking functions as non-throwing matters |\n| Stack Unwinding | Stack unwinding mechanics in depth |\n| Exception Best Practices | Exception safety guarantees and patterns for writing safe code |\n\n\nBy the end of the section, you'll know not just how to throw and catch, but also how to design APIs that use exceptions well, what to mark `noexcept`, and how to write code that remains in a valid state even when an exception passes through it.\n\n---\n\n# Summary\n\n- An exception is a typed value plus a control-flow jump that signals an abnormal condition and propagates it up the call stack until a handler claims it.\n- Error codes can be silently ignored, mix error and value channels, and force every intermediate function to forward failures by hand. Exceptions address all three problems.\n- Logic errors are bugs the programmer should have prevented; runtime errors come from conditions outside the program's control. Both are reported through exceptions but call for different responses.\n- The high-level flow is **throw** (create the exception and stop the function), **unwind** (destroy local objects on the way up), **catch** (run a handler that matches the exception's type).\n- Throw when a function can't fulfill its contract, a precondition is violated, or a failure is best handled several frames up. Use return values like `std::optional` for routine \"no result\" outcomes.\n- Exceptions are cheap on the happy path on modern compilers and expensive on the throw path. They are designed for rare, exceptional conditions, not for hot-loop control flow.\n- Don't throw from destructors, don't use exceptions for routine outcomes, and don't reach for exceptions when a normal return value expresses the situation more clearly.\n\nThe next lesson, **try, catch & throw**, gets into the actual syntax: where to put a `try` block, how `catch` clauses are written, what `throw` accepts as an operand, and how rethrowing works. Once you've seen the syntax, the rest of the section can dig into multiple handlers, the standard exception hierarchy, custom exception types, and the runtime mechanics underneath.","pageType":"cpp"}

Exception Basics

Get Premium