Exception Handling Constructs

Programming Language & Its Applications — Generic Programming and Exception Handling, NEC licence examination syllabus (Nepal Engineering Council).

Exception Handling Constructs

try, throw and catch — separating the detection of an error from the code that can deal with it.

🌍 Where this lives: exceptions exist because error codes get ignored. In C, fopen returns NULL and malloc returns NULL, and studies of real codebases found that a large fraction of return values were never checked — every unchecked one a latent crash. An exception cannot be ignored: if nobody handles it, the program terminates loudly rather than continuing with corrupt state. That is the whole design argument. But it is contested — Google's C++ style guide bans exceptions, game engines disable them for performance, and Rust chose Result instead. Search "why Google style guide bans exceptions" to hear the strongest case against, then "exception safety guarantees" for the case in favour.

The three keywords

try { // code that MIGHT throw if (bad) throw SomeType(args); } catch (const SpecificType &e) { // handle this kind of problem } catch (const std::exception &e) { // handle anything deriving from std::exception } catch (...) { // catch-all: any type at all } throw raises an exception — an object of ANY type try marks a region whose exceptions you want to handle catch a handler, selected by the THROWN TYPE WHAT HAPPENS ON A throw, in order: 1. the thrown object is COPIED to a safe place (implementations use a special area, not the stack being unwound) 2. STACK UNWINDING begins: the current function exits, and every fully-constructed local object has its DESTRUCTOR called 3. this repeats up the call chain until a matching catch is found 4. the handler runs 5. execution continues AFTER the handler's closing brace — NOT back at the throw point. There is no "resume". IF NO HANDLER MATCHES: std::terminate() is called, which by default calls std::abort() — the program dies, typically without unwinding the remaining stack. So an uncaught exception may skip destructors. MATCHING RULES — a catch matches if the handler's type is: · the SAME type (ignoring top-level const/volatile) · a BASE CLASS of the thrown type (public inheritance) · a void* for any object pointer · caught by catch(...) NO implicit conversions are applied: throw 42; → catch(double) does NOT match throw 3.14; → catch(int) does NOT match This is unlike overload resolution, and it surprises people.

basics.cpp

#include <iostream>
#include <stdexcept>
#include <string>

class Guard {
    std::string name;
public:
    Guard(std::string n) : name(std::move(n)) {
        std::cout << "    +" << name << "\n";
    }
    ~Guard() { std::cout << "    -" << name
                         << " (destructor ran)\n"; }
};

void level3(bool fail) {
    Guard g("g3");
    if (fail) throw std::runtime_error("failure in level3");
    std::cout << "    level3 finished normally\n";
}
void level2(bool fail) { Guard g("g2"); level3(fail); }
void level1(bool fail) { Guard g("g1"); level2(fail); }

int main() {
    std::cout << "  --- normal path ---\n";
    level1(false);

    std::cout << "  --- throwing path ---\n";
    try {
        level1(true);
        std::cout << "    NEVER REACHED\n";
    }
    catch (const std::runtime_error &e) {
        std::cout << "    caught: " << e.what() << "\n";
    }
    std::cout << "  --- execution continues here ---\n";

    /* you can throw ANY type — but there are good reasons
       to throw only exception classes (see below) */
    try { throw 42; }
    catch (int n) { std::cout << "  caught an int: " << n << "\n"; }

    try { throw std::string("a string"); }
    catch (const std::string &s) {
        std::cout << "  caught a string: " << s << "\n";
    }

    /* NO implicit conversion: catch(double) will NOT
       catch a thrown int */
    try {
        try { throw 7; }
        catch (double d) { std::cout << "  never: " << d << "\n"; }
    }
    catch (int n) {
        std::cout << "  int fell through to the outer catch: "
                  << n << "\n";
    }
    return 0;
}
Output:
  --- normal path ---
    +g1
    +g2
    +g3
    level3 finished normally
    -g3 (destructor ran)
    -g2 (destructor ran)
    -g1 (destructor ran)
  --- throwing path ---
    +g1
    +g2
    +g3
    -g3 (destructor ran)
    -g2 (destructor ran)
    -g1 (destructor ran)
    caught: failure in level3
  --- execution continues here ---
  caught an int: 42
  caught a string: a string
  int fell through to the outer catch: 7

Read the throwing path carefully — the ORDER is the whole lesson: +g1 +g2 +g3 three guards constructed going down -g3 -g2 -g1 all three destroyed, in REVERSE order caught: ... the handler runs LAST Destructors run BEFORE the catch block, during unwinding. That ordering is what makes RAII work: by the time your handler executes, every file is closed, every lock released, every unique_ptr freed — automatically, with no cleanup code at the throw site or in the handler. Also note "NEVER REACHED" was not printed. Once level1 throws, the rest of the try block is abandoned. There is no mechanism to resume at the throw point — that is a deliberate design decision (some older languages had resumable exceptions and the feature proved unusable). And the last case proves NO CONVERSIONS: catch(double) did not catch a thrown int, even though int→double is a standard conversion everywhere else in C++. Exception matching is almost exact — same type, or a public base class.

The "no implicit conversions" rule has a practical consequence: catch (std::exception e) by value compiles but is wrong. It copies the exception, which slices a derived exception down to its base and loses the real message. Always catch by const reference — catch (const std::exception &e).

The standard exception hierarchy

std::exception │ virtual const char* what() const ┌─────────────────┼─────────────────┐ │ │ │ logic_error runtime_error bad_alloc │ │ bad_cast │ │ bad_typeid ├ invalid_argument ├ range_error bad_function_call ├ domain_error ├ overflow_error ├ length_error └ underflow_error └ out_of_range (+ system_error → ios_base::failure) WHEN TO USE WHICH — the intended distinction: logic_error — a BUG in the program. The caller violated a precondition, and the fix is to change the code. invalid_argument a parameter value makes no sense out_of_range an index or key is outside bounds length_error an object would exceed its max size domain_error the input is outside the maths domain runtime_error — an EXTERNAL condition the program could not have predicted. The fix is to handle it at runtime. range_error a result is outside the valid range overflow_error arithmetic overflow system_error an OS-level failure All of them are constructed with a message: throw std::invalid_argument("age must be positive"); and retrieved with e.what(). WHY DERIVE FROM std::exception: · one catch(const std::exception&) handles everything · what() gives a uniform way to get a message · library code can catch and log without knowing your types Throwing an int or a string works but gives none of that.

hierarchy.cpp

#include <iostream>
#include <stdexcept>
#include <vector>
#include <string>
#include <cmath>

/* a small validated class using the right exception types */
class Student {
    std::string name;
    int         age;
    std::vector<double> marks;
public:
    Student(std::string n, int a) : name(std::move(n)), age(a) {
        if (name.empty())
            throw std::invalid_argument("name must not be empty");
        if (age < 5 || age > 120)
            throw std::out_of_range("age " + std::to_string(a)
                                    + " is implausible");
    }
    void addMark(double m) {
        if (m < 0 || m > 100)
            throw std::domain_error("mark must be 0..100");
        if (marks.size() >= 8)
            throw std::length_error("at most 8 subjects");
        marks.push_back(m);
    }
    double average() const {
        if (marks.empty())
            throw std::runtime_error("no marks recorded yet");
        double s = 0;
        for (double m : marks) s += m;
        return s / marks.size();
    }
    const std::string& getName() const { return name; }
};

int main() {
    /* the happy path */
    Student ok("Ram Bahadur", 22);
    ok.addMark(87.5); ok.addMark(91.0); ok.addMark(76.5);
    std::cout << "  " << ok.getName() << " average = "
              << ok.average() << "\n";

    /* each failure caught by its SPECIFIC type */
    struct Case { const char *label; void (*fn)(); };

    try { Student bad("", 20); }
    catch (const std::invalid_argument &e) {
        std::cout << "  invalid_argument: " << e.what() << "\n";
    }

    try { Student bad("Sita", 200); }
    catch (const std::out_of_range &e) {
        std::cout << "  out_of_range    : " << e.what() << "\n";
    }

    try { ok.addMark(150); }
    catch (const std::domain_error &e) {
        std::cout << "  domain_error    : " << e.what() << "\n";
    }

    try { Student e("Hari", 20); e.average(); }
    catch (const std::runtime_error &e) {
        std::cout << "  runtime_error   : " << e.what() << "\n";
    }

    /* ONE handler for the whole family, via the base class */
    for (int badAge : {3, 500}) {
        try { Student s("Test", badAge); }
        catch (const std::exception &e) {
            std::cout << "  base handler    : " << e.what() << "\n";
        }
    }

    /* library exceptions use the same hierarchy */
    try {
        std::vector<int> v{1,2,3};
        std::cout << v.at(10);
    }
    catch (const std::out_of_range &e) {
        std::cout << "  vector::at threw: out_of_range\n";
    }

    try { std::string s; s.at(5); }
    catch (const std::out_of_range&) {
        std::cout << "  string::at threw: out_of_range\n";
    }
    return 0;
}
Output:
  Ram Bahadur average = 85
  invalid_argument: name must not be empty
  out_of_range    : age 200 is implausible
  domain_error    : mark must be 0..100
  runtime_error   : no marks recorded yet
  base handler    : age 3 is implausible
  base handler    : age 500 is implausible
  vector::at threw: out_of_range
  string::at threw: out_of_range

Checking the average: (87.5 + 91.0 + 76.5) / 3 = 255.0 / 3 = 85 ✔ The design lesson: the SAME two invalid ages were caught once by catch(const std::out_of_range&) and once by catch(const std::exception&). Because out_of_range derives from logic_error which derives from exception, both handlers match — and the compiler picks the FIRST one listed. That is why handler ORDER matters, and it is the subject of the next topic. Put the most DERIVED types first; a catch(const std::exception&) placed first would swallow everything and the specific handlers below it would be unreachable (gcc warns: "exception of type ... will be caught by earlier handler"). Notice also that vector::at and string::at throw std::out_of_range — the same type your own code throws. That uniformity is the payoff of using the standard hierarchy instead of inventing your own error types.

Worked example — exceptions versus error codes

vs_codes.cpp

#include <iostream>
#include <stdexcept>
#include <string>

/* ---- THE ERROR-CODE APPROACH ---- */
enum class Err { Ok, DivZero, Negative, TooBig };

Err safeDivide(double a, double b, double &out) {
    if (b == 0) return Err::DivZero;
    out = a / b;
    return Err::Ok;
}
Err safeSqrt(double x, double &out) {
    if (x < 0) return Err::Negative;
    out = std::sqrt(x);
    return Err::Ok;
}

/* the caller must check EVERY step — and can forget to */
Err computeCodes(double a, double b, double &result) {
    double q;
    Err e = safeDivide(a, b, q);
    if (e != Err::Ok) return e;          /* check 1 */
    double r;
    e = safeSqrt(q, r);
    if (e != Err::Ok) return e;          /* check 2 */
    e = safeDivide(100, r, result);
    if (e != Err::Ok) return e;          /* check 3 */
    return Err::Ok;
}

/* ---- THE EXCEPTION APPROACH ---- */
double divide(double a, double b) {
    if (b == 0) throw std::domain_error("division by zero");
    return a / b;
}
double root(double x) {
    if (x < 0) throw std::domain_error("sqrt of a negative");
    return std::sqrt(x);
}

/* the happy path is UNCLUTTERED — no checks at all */
double computeExc(double a, double b) {
    return divide(100, root(divide(a, b)));
}

int main() {
    double r;

    /* error codes */
    for (auto [a, b] : {std::pair<double,double>{50, 2},
                        {50, 0}, {-50, 2}}) {
        Err e = computeCodes(a, b, r);
        std::cout << "  codes  a=" << a << " b=" << b << " -> ";
        switch (e) {
            case Err::Ok:       std::cout << r << "\n"; break;
            case Err::DivZero:  std::cout << "DivZero\n"; break;
            case Err::Negative: std::cout << "Negative\n"; break;
            default:            std::cout << "other\n";
        }
    }

    /* exceptions */
    for (auto [a, b] : {std::pair<double,double>{50, 2},
                        {50, 0}, {-50, 2}}) {
        std::cout << "  exc    a=" << a << " b=" << b << " -> ";
        try { std::cout << computeExc(a, b) << "\n"; }
        catch (const std::exception &e) {
            std::cout << e.what() << "\n";
        }
    }
    return 0;
}
Output:
  codes  a=50 b=2 -> 20
  codes  a=50 b=0 -> DivZero
  codes  a=-50 b=2 -> Negative
  exc    a=50 b=2 -> 20
  exc    a=50 b=0 -> division by zero
  exc    a=-50 b=2 -> sqrt of a negative

Verifying the successful case, a=50 b=2: divide(50, 2) = 25 root(25) = 5 divide(100, 5) = 20 ✔ both approaches agree COMPARE THE TWO computeXXX FUNCTIONS: computeCodes: 11 lines, 3 explicit checks, an out-parameter, and the actual computation is buried computeExc: 1 line, expresses the FORMULA directly That is the real argument for exceptions: the error handling moves OUT of the normal path, so the normal path reads like the algorithm it implements. THE HONEST TRADE-OFFS: EXCEPTIONS + cannot be ignored — an unhandled one terminates + carry rich information (a message, a type, a chain) + the happy path stays clean + constructors can report failure (they have no return value, so error codes are impossible there) − a throw is SLOW: typically microseconds, versus nanoseconds for a comparison. Fine for genuine errors, unusable in a hot loop. − the binary grows ~5-15% for unwind tables − writing exception-SAFE code is genuinely hard − control flow becomes non-local and harder to follow ERROR CODES + predictable, near-zero cost + control flow is visible in the source − easy to ignore, and ignoring is silent − clutter every call site − cannot report constructor failure − an out-parameter is needed for the real result USE EXCEPTIONS FOR: genuinely exceptional conditions — a missing file, a failed allocation, invalid user input at a boundary, a constructor that cannot establish its invariant. USE RETURN VALUES FOR: expected outcomes. "Key not found" in a map lookup is not exceptional; that is why std::map::find returns end() rather than throwing.

🌍 Go further: the middle ground has arrived. C++23's std::expected<T, E> returns either a value or an error in one object, with no throw cost and no way to accidentally ignore it — the same design as Rust's Result<T, E> and Haskell's Either. C++17's std::optional<T> already covers "a value or nothing". Meanwhile noexcept lets you promise a function never throws, which the compiler uses to generate better code — and std::vector checks it to decide whether moving elements during reallocation is safe. Search "std::expected vs exceptions" and "why noexcept matters for vector".

💡 Exam angle: define try, throw, catch and describe stack unwinding — destructors of local objects run before the handler, which is a favourite trace question. State that execution resumes after the handler, never at the throw point, and that an unmatched exception calls std::terminate. Know the standard hierarchy (logic_error for bugs, runtime_error for external conditions, both under std::exception with what()). Two high-value details: no implicit conversions in matching, and always catch by const reference to avoid slicing.

Syllabus points

try, catch, throw

Create a free account to tick topics off, take notes as you read, watch the video lessons and get a day-by-day study plan built around your exam date.