{"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++ provides 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 cover 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 signal that something has gone wrong and the function 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\nAn exception is a typed value plus a control-flow jump, both bundled into a single language feature.\n\nConsider ordering something from an online store. A user adds three items to a cart, clicks \"Place order\", and the system tries to charge the card. If the card is declined, the order can't be completed. The checkout function doesn't know whether the user wants to retry, switch to a different card, save the cart for later, or cancel. That decision belongs to 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 do the 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 accepts ignored return values and lets execution 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.\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 dropped without notice.\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. Three patterns make error codes painful.\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 boilerplate.\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 boilerplate 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 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\nExceptions are not free. They are cheap on the success path and expensive on the throw path. A later section covers the cost in detail.\n\n---\n\n# Runtime Errors vs Logic Errors\n\nWhen writing code that throws exceptions, it helps to distinguish two broad categories of \"things that went wrong.\" The standard library uses this split when organising its built-in exception types, but the categories are useful even before learning 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. Code review cannot 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\n\nThe exception mechanism in C++ comes down to three steps.\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\nThe same idea in code:\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\n`\"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 automatically.\n\nThe 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 used everywhere. Three patterns make exceptions 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. Many user-typed searches won't match anything; that's not a failure, it's what the function does. Use a return value (`std::optional` works well) and reserve exceptions for the cases that 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 routine, so throwing would be misleading. `std::optional` describes what the function returns: maybe a price, maybe nothing.\n\n**Don't use exceptions for input validation in tight loops.** Parsing a million product records where a few percent are malformed, and 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. Advanced techniques exist to work around this, but the safest rule is: destructors should never throw.\n\nOn modern compilers, an exception that is never thrown costs almost nothing on the success 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# A Larger Example\n\nThe following e-commerce scenario 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 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\nAfter completing the section, you will know how to throw and catch, 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.","pageType":"cpp"}

Exception Basics

Get Premium