Error Handling

std::runtime_error (and the other standard exception types, Module 3) provide a .what() method returning a description of what went wrong — "Division by zero" in this example, exactly the message passed to the constructor when the exception was created.

Every standard exception type inherits from a common base, std::exception — directly applying Phase 6's inheritance concepts. This is exactly why .what() works consistently across all of them: it's declared once, virtually, in the shared base class.

class InsufficientFundsError : public std::runtime_error {
public:
    InsufficientFundsError() : std::runtime_error("Insufficient funds") {}
};

throw InsufficientFundsError();

You can create your OWN exception type by inheriting from a standard one — genuinely just Phase 6 Module 3's derived-class-constructor pattern, applied to build a domain-specific error type that's still fully compatible with catch (const std::runtime_error&) and .what().

try {
    processOrder(orderId);
} catch (const std::invalid_argument& e) {
    std::cout << "Bad input: " << e.what() << std::endl;
} catch (const std::runtime_error& e) {
    std::cout << "Runtime problem: " << e.what() << std::endl;
} catch (...) {
    std::cout << "Something else entirely went wrong." << std::endl;
}

C++ checks each catch block IN ORDER and uses the first one whose type matches — genuinely similar in spirit to Phase 1 Module 8's else-if chain. catch (...) is a genuine catch-all, matching literally anything not caught by an earlier, more specific block.

void processData() {
    int* data = new int[1000];

    riskyOperation();   // throws an exception!

    delete[] data;   // NEVER REACHED — the exception skipped right past this line
}

When an exception is thrown, C++ immediately unwinds the stack, skipping any remaining code in the current function — including a manual delete that would otherwise have run. This is a genuine, real memory leak (Phase 4 Module 7), specifically caused by exceptions interacting badly with manual memory management.

void processData() {
    std::unique_ptr<int[]> data = std::make_unique<int[]>(1000);

    riskyOperation();   // throws — but data's destructor STILL runs during stack unwinding!
}   // even though this line is never reached, data was already safely cleaned up

Because Phase 8's smart pointers tie cleanup to the object's own destructor, and destructors are GUARANTEED to run during stack unwinding (as the Pre-Course and Phase 5 first established), data is genuinely cleaned up correctly — even though the function never reaches its last line. This is exactly why professional C++ code overwhelmingly prefers RAII/smart pointers over manual new/delete.

Throwing and catching an exception carries real runtime overhead, well beyond a simple bool check or comparison. Using exceptions for routine, EXPECTED situations — like validating everyday user input — is both a performance concern and, often, a design smell: exceptions are meant for genuinely exceptional circumstances, not ordinary control flow.

Build a function that parses a string as an age (a whole number between 0 and 130), throwing a custom exception for genuinely malformed input, while a separate, simpler function checks whether a parsed age qualifies as "senior" (65+) using a plain bool — deliberately applying both strategies where each genuinely fits.

• InvalidAgeError (Module 3) provides a genuinely meaningful, specific exception type rather than a generic one.
• parseAge catches the STL's own std::invalid_argument from std::stoi and re-throws it as the more specific InvalidAgeError — a real, common pattern for translating a library's generic errors into your own domain-specific ones.
• isSenior deliberately uses a plain bool, not an exception — an age simply not being 65+ is entirely ordinary, expected behavior (Module 6's judgment call, applied directly).
• The loop's single try/catch handles every genuinely malformed input without crashing the whole program.