Multiple Exception Handling

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

Multiple Exception Handling

Several catch blocks on one try — and why their order decides which one runs.

🌍 Where this lives: any real operation can fail several ways, and each way often needs a different response. Opening a database connection might fail because the network is down (retry), the password is wrong (stop and tell the user), or the query is malformed (a bug, log it and fix the code). One handler cannot do all three. Getting the order wrong is a genuine production bug: put the generic handler first and every specific one below it becomes dead code that the compiler will happily accept. Search "catch block order most derived first" — and note that GCC's -Woverloaded-virtual family includes a warning for exactly this mistake.

The ordering rule

try { risky(); } catch (const std::out_of_range &e) { /* most specific */ } catch (const std::logic_error &e) { /* its base */ } catch (const std::exception &e) { /* the root */ } catch (...) { /* everything */ } HANDLERS ARE TRIED IN SOURCE ORDER, top to bottom. The FIRST one whose type matches wins. There is no "best match" search like overload resolution — it is strictly first-match. Because out_of_range derives from logic_error derives from exception, ALL THREE would match an out_of_range. Only the first runs. REVERSE THE ORDER AND THE CODE BREAKS: catch (const std::exception &e) { ... } ← catches all catch (const std::out_of_range &e) { ... } ← UNREACHABLE g++ warning: exception of type 'std::out_of_range' will be caught by earlier handler for 'std::exception' It compiles, and the specific handler simply never runs. THE RULE: order handlers from MOST DERIVED to LEAST DERIVED. catch(...) must always be LAST — it matches anything, so nothing after it is reachable. WHAT A HANDLER MATCHES: · the exact type (top-level const/volatile ignored) · any PUBLIC base class of the thrown type · void* for any object pointer type · catch(...) for absolutely anything WHAT IT DOES NOT MATCH: · a DERIVED class when you throw the base throw std::exception(); catch (const std::out_of_range&) ✗ no match · anything requiring a conversion throw 42; catch(double) ✗ no match · a PRIVATE base class

ordering.cpp

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

void thrower(int which) {
    switch (which) {
        case 1: throw std::out_of_range("index 99 is out of range");
        case 2: throw std::invalid_argument("age cannot be negative");
        case 3: throw std::runtime_error("the network is unreachable");
        case 4: throw std::bad_alloc();
        case 5: throw 42;
        case 6: throw std::string("a bare string");
        default: std::cout << "      no throw\n";
    }
}

/* CORRECT ordering: derived -> base -> catch-all */
void handleWell(int which) {
    std::cout << "    case " << which << ": ";
    try { thrower(which); }
    catch (const std::out_of_range &e) {
        std::cout << "[out_of_range]    " << e.what() << "\n";
    }
    catch (const std::logic_error &e) {
        std::cout << "[logic_error]     " << e.what() << "\n";
    }
    catch (const std::runtime_error &e) {
        std::cout << "[runtime_error]   " << e.what() << "\n";
    }
    catch (const std::exception &e) {
        std::cout << "[std::exception]  " << e.what() << "\n";
    }
    catch (int n) {
        std::cout << "[int]             " << n << "\n";
    }
    catch (...) {
        std::cout << "[catch-all]       unknown type\n";
    }
}

/* WRONG ordering: the base swallows everything */
void handleBadly(int which) {
    std::cout << "    case " << which << ": ";
    try { thrower(which); }
    catch (const std::exception &e) {
        std::cout << "[exception FIRST] " << e.what() << "\n";
    }
    catch (const std::out_of_range &e) {
        std::cout << "[NEVER REACHED]\n";
    }
    catch (...) {
        std::cout << "[catch-all]       non-std type\n";
    }
}

int main() {
    std::cout << "  CORRECT ordering:\n";
    for (int i = 1; i <= 7; i++) handleWell(i);

    std::cout << "  WRONG ordering (base first):\n";
    for (int i = 1; i <= 3; i++) handleBadly(i);
    handleBadly(6);
    return 0;
}
Output:
  CORRECT ordering:
    case 1: [out_of_range]    index 99 is out of range
    case 2: [logic_error]     age cannot be negative
    case 3: [runtime_error]   the network is unreachable
    case 4: [std::exception]  std::bad_alloc
    case 5: [int]             42
    case 6: [catch-all]       unknown type
    case 7:       no throw
  WRONG ordering (base first):
    case 1: [exception FIRST] index 99 is out of range
    case 2: [exception FIRST] age cannot be negative
    case 3: [exception FIRST] the network is unreachable
    case 6: [catch-all]       non-std type

Trace each correct case to see the first-match rule: case 1 out_of_range · catch(out_of_range&) MATCHES exactly → wins (logic_error and exception would also match, but come later) case 2 invalid_argument · catch(out_of_range&) no — sibling, not a base · catch(logic_error&) MATCHES — invalid_argument derives from logic_error → wins case 3 runtime_error · out_of_range, logic_error: no (different branch) · catch(runtime_error&) MATCHES exactly → wins case 4 bad_alloc · bad_alloc derives DIRECTLY from std::exception, not from logic_error or runtime_error · catch(exception&) MATCHES → wins Note what() gave "std::bad_alloc" — the standard message. case 5 int 42 · no std::exception handler matches a plain int · catch(int) MATCHES → wins case 6 std::string · nothing specific matches · catch(...) MATCHES → the safety net In the WRONG version, cases 1, 2 and 3 all hit [exception FIRST] and the specific out_of_range handler printed nothing — it is unreachable. Case 6 still reaches catch(...) because a std::string is not a std::exception. That is exactly the bug: three distinct failure modes collapsed into one generic handler, losing the ability to respond differently to each.

Note that bad_alloc fell through to catch(const std::exception&) rather than logic_error or runtime_error. It derives directly from std::exception, as do bad_cast and bad_typeid. So a handler catching only logic_error and runtime_error misses allocation failures entirely — a real gap in code that thinks it has covered everything.

Worked example — one operation, many failure modes

multi_fail.cpp

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

/* Custom exception types, each carrying its own data —
   because different failures need different information */
class ParseError : public std::runtime_error {
    int lineNo;
public:
    ParseError(const std::string &msg, int line)
        : std::runtime_error(msg), lineNo(line) {}
    int line() const { return lineNo; }
};

class RangeError : public std::out_of_range {
    double value, lo, hi;
public:
    RangeError(double v, double a, double b)
        : std::out_of_range("value out of range"),
          value(v), lo(a), hi(b) {}
    double got() const { return value; }
    double min() const { return lo; }
    double max() const { return hi; }
};

class MissingField : public std::invalid_argument {
    std::string field;
public:
    MissingField(const std::string &f)
        : std::invalid_argument("missing field: " + f), field(f) {}
    const std::string& name() const { return field; }
};

/* parse "roll,name,marks" with full validation */
struct Record { int roll; std::string name; double marks; };

Record parseLine(const std::string &line, int lineNo) {
    std::istringstream is(line);
    std::string rollStr, name, marksStr;

    if (!std::getline(is, rollStr, ',')) throw MissingField("roll");
    if (!std::getline(is, name,    ',')) throw MissingField("name");
    if (!std::getline(is, marksStr))     throw MissingField("marks");

    Record r;
    try {
        r.roll = std::stoi(rollStr);
    } catch (const std::exception&) {
        throw ParseError("roll is not an integer: " + rollStr, lineNo);
    }
    try {
        r.marks = std::stod(marksStr);
    } catch (const std::exception&) {
        throw ParseError("marks is not a number: " + marksStr, lineNo);
    }

    if (name.empty()) throw MissingField("name");
    if (r.marks < 0 || r.marks > 100)
        throw RangeError(r.marks, 0, 100);
    r.name = name;
    return r;
}

int main() {
    std::vector<std::string> lines = {
        "101,Ram Bahadur,87.5",     /* valid            */
        "102,Sita Devi,150",        /* marks out of range */
        "abc,Hari Prasad,76",       /* roll not a number  */
        "104,,68",                  /* empty name         */
        "105,Gita",                 /* missing marks      */
        "106,Bikash,ninety"         /* marks not a number */
    };

    int ok = 0, failed = 0;
    for (size_t i = 0; i < lines.size(); i++) {
        std::cout << "  line " << (i+1) << ": ";
        try {
            Record r = parseLine(lines[i], int(i+1));
            std::cout << "OK  " << r.roll << " " << r.name
                      << " " << r.marks << "\n";
            ++ok;
        }
        /* most specific first, each using its OWN data */
        catch (const RangeError &e) {
            std::cout << "RANGE  got " << e.got()
                      << ", allowed " << e.min() << ".."
                      << e.max() << "\n";
            ++failed;
        }
        catch (const MissingField &e) {
            std::cout << "FIELD  '" << e.name()
                      << "' is required\n";
            ++failed;
        }
        catch (const ParseError &e) {
            std::cout << "PARSE  line " << e.line()
                      << ": " << e.what() << "\n";
            ++failed;
        }
        catch (const std::exception &e) {
            std::cout << "OTHER  " << e.what() << "\n";
            ++failed;
        }
    }
    std::cout << "  --- " << ok << " accepted, "
              << failed << " rejected ---\n";
    return 0;
}
Output:
  line 1: OK  101 Ram Bahadur 87.5
  line 2: RANGE  got 150, allowed 0..100
  line 3: PARSE  line 3: roll is not an integer: abc
  line 4: FIELD  'name' is required
  line 5: FIELD  'marks' is required
  line 6: PARSE  line 6: marks is not a number: ninety
  --- 1 accepted, 5 rejected ---

Each handler used information ONLY its exception type carries: RangeError → got(), min(), max() — the offending value and the allowed bounds MissingField → name() — which field ParseError → line() — where in the input A single catch(const std::exception&) could print what() but could not report "allowed 0..100" or "line 3", because that data does not exist on the base class. THAT is the reason to define custom exception types: not to have more names, but to CARRY the data the handler needs to respond intelligently. Note also that ParseError derives from runtime_error while MissingField derives from invalid_argument (a logic_error). That is the intended distinction: · malformed input from an external file is a RUNTIME condition — the program was fine, the data was not · a missing required field is arguably a caller/logic problem Choosing correctly makes catch(const std::logic_error&) meaningful in higher-level code. And the ordering matters here too: MissingField derives from invalid_argument, so a catch(const std::invalid_argument&) placed above it would swallow it and lose name().

Nested try blocks

nested.cpp

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

/* An inner try handles what it can and lets the rest
   propagate outward — the normal layered design. */
double processOne(const std::string &s) {
    if (s == "zero")  throw std::domain_error("division by zero");
    if (s == "fatal") throw std::runtime_error("unrecoverable");
    if (s == "junk")  throw std::invalid_argument("not a number");
    return std::stod(s) * 2;
}

int main() {
    std::vector<std::string> inputs =
        {"21", "junk", "zero", "7.5", "fatal", "3"};

    double total = 0;
    int    skipped = 0;

    try {
        for (const auto &s : inputs) {
            /* INNER try: recover from per-item problems */
            try {
                double v = processOne(s);
                total += v;
                std::cout << "    " << s << " -> " << v << "\n";
            }
            catch (const std::invalid_argument &e) {
                std::cout << "    " << s << " -> skipped ("
                          << e.what() << ")\n";
                ++skipped;
            }
            catch (const std::domain_error &e) {
                std::cout << "    " << s << " -> skipped ("
                          << e.what() << ")\n";
                ++skipped;
            }
            /* runtime_error is NOT caught here — it
               propagates to the OUTER try */
        }
        std::cout << "    loop completed\n";
    }
    catch (const std::runtime_error &e) {
        std::cout << "  ABORTED by: " << e.what() << "\n";
    }

    std::cout << "  total=" << total << " skipped=" << skipped
              << "\n";
    return 0;
}
Output:
    21 -> 42
    junk -> skipped (not a number)
    zero -> skipped (division by zero)
    7.5 -> 15
  ABORTED by: unrecoverable
  total=57 skipped=2

Verifying: 21×2 = 42, then 7.5×2 = 15, so total = 57 ✔ And "3" was NEVER processed — the loop was abandoned when "fatal" threw a runtime_error that the inner try does not handle. THE LAYERED DESIGN this demonstrates: INNER handlers → recoverable, per-item problems. Log, skip, and continue the loop. OUTER handler → fatal conditions. Abandon the whole operation. The inner try deliberately does NOT catch runtime_error, so it propagates. That is not an oversight — it is how you express "this level cannot fix this". The alternative, catch(...) in the inner block, would have swallowed the fatal error and continued processing with the program in an unknown state. Catching too broadly is worse than not catching at all. Note the "loop completed" line was not printed. Once the exception left the loop, the rest of the outer try was abandoned too — including code after the loop.

🌍 Go further: C++11 added nested exceptions via std::nested_exception and std::throw_with_nested, which let a handler catch a low-level error, wrap it in a higher-level one, and preserve the whole chain — so a "cannot load config" error still carries the underlying "file not found" inside it. Java has had this as getCause() since 1.4 and it is invaluable for debugging layered systems. Search "std::throw_with_nested rethrow_if_nested"; the printing helper is a short recursive function worth writing once.

💡 Exam angle: state the first-match, not best-match rule and therefore that handlers must be ordered most derived first, with catch(...) last. Be ready to trace which handler catches each of several throws — that is the standard question. Know that a handler matches the exact type or any public base class, with no implicit conversions. Mention that bad_alloc derives directly from std::exception, and that a base-first ordering produces unreachable handlers that the compiler only warns about.

Syllabus points

Multiple catch blocks

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.