Rethrowing Exception

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

Rethrowing an Exception

Catch it, do something local, then pass it on — throw; with no operand.

🌍 Where this lives: rethrowing is how layered software adds context without taking responsibility. A database driver catches a socket error, logs "connection to db-primary:5432 lost", and rethrows so the application layer can decide whether to retry a replica. Neither layer alone knows enough to handle it — the driver knows the details, the application knows the policy. Every serious framework does this at every boundary. Getting it wrong (throw e; instead of throw;) silently destroys the exception's real type, which is one of the most quietly damaging bugs in C++. Search "throw vs throw e slicing".

`throw;` versus `throw e;`

Inside a catch block, a bare throw rethrows the CURRENT exception, unchanged: catch (const std::exception &e) { log(e.what()); throw; /* rethrow — preserves everything */ } Compare with rethrowing by name: catch (const std::exception &e) { throw e; /* WRONG in almost every case */ } THE DIFFERENCE — and it is not subtle: throw; · rethrows the ORIGINAL object · the DYNAMIC (actual) type is preserved · no copy is made · outer handlers see the real derived type throw e; · throws a COPY of e · e is declared as std::exception&, so the copy is a std::exception — the derived part is SLICED OFF · custom data (a line number, a field name) is LOST · outer catch(const MyError&) no longer matches throw; outside any catch block → std::terminate() This is the same object-slicing problem as copying a Derived into a Base variable, appearing in a place where it does real damage. WHEN `throw e;` IS ACTUALLY CORRECT: only when you deliberately want to change the exception, and then you would normally throw a DIFFERENT type: catch (const LowLevelError &e) { throw HighLevelError("could not load config: " + std::string(e.what())); } That is exception TRANSLATION, not rethrowing.

rethrow.cpp

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

/* a custom exception carrying EXTRA data */
class DiskError : public std::runtime_error {
    int errcode;
public:
    DiskError(const std::string &m, int c)
        : std::runtime_error(m), errcode(c) {}
    int code() const { return errcode; }
};

void lowLevel() { throw DiskError("sector read failed", 27); }

/* CORRECT: bare throw preserves the DiskError type */
void middleGood() {
    try { lowLevel(); }
    catch (const std::exception &e) {
        std::cout << "    [middleGood] logging: " << e.what() << "\n";
        throw;                      /* rethrow, unchanged */
    }
}

/* WRONG: throw e; slices DiskError down to std::exception */
void middleBad() {
    try { lowLevel(); }
    catch (const std::exception &e) {
        std::cout << "    [middleBad]  logging: " << e.what() << "\n";
        throw e;                    /* COPY — type lost */
    }
}

int main() {
    std::cout << "  --- with bare throw; ---\n";
    try { middleGood(); }
    catch (const DiskError &e) {
        std::cout << "    caught DiskError, code=" << e.code()
                  << " msg=" << e.what() << "\n";
    }
    catch (const std::exception &e) {
        std::cout << "    caught only std::exception: "
                  << e.what() << "\n";
    }

    std::cout << "  --- with throw e; ---\n";
    try { middleBad(); }
    catch (const DiskError &e) {
        std::cout << "    caught DiskError, code=" << e.code() << "\n";
    }
    catch (const std::exception &e) {
        std::cout << "    caught only std::exception: "
                  << e.what() << "  <-- DiskError data LOST\n";
    }
    return 0;
}
Output:
  --- with bare throw; ---
    [middleGood] logging: sector read failed
    caught DiskError, code=27 msg=sector read failed
  --- with throw e; ---
    [middleBad]  logging: sector read failed
    caught only std::exception: std::exception  <-- DiskError data LOST

The two outputs are the entire lesson. With `throw;` the original DiskError object was rethrown, so catch(const DiskError&) matched and e.code() returned 27. With `throw e;` e was declared std::exception&, so `throw e` copied only the std::exception SUB-OBJECT. The DiskError part — including errcode = 27 — was discarded. The outer catch(const DiskError&) did not match, and what() returned the base class's generic "std::exception" instead of "sector read failed". Look at what was lost: the error CODE the caller needed to decide what to do, and the MESSAGE describing what happened. The program still runs, still reports "an error", and is now unable to act on it. THE RULE, with no exceptions worth remembering: inside a catch block, to pass the exception on, write `throw;` — never `throw e;`

This bug is especially insidious because the logging line still works. The handler prints the correct message, so a developer reading the log sees the right error — and only the outer layer, whose specific handler silently stopped matching, is broken. That is a bug you find weeks later.

Worked example — the log-and-propagate pattern

layers.cpp

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

/* ---- layer 1: the resource, which is always released ---- */
class Connection {
    std::string host;
    bool open;
public:
    Connection(std::string h) : host(std::move(h)), open(true) {
        std::cout << "      + connected to " << host << "\n";
    }
    ~Connection() {
        if (open) std::cout << "      - closed " << host << "\n";
    }
    void query(const std::string &q) {
        if (q.find("DROP") != std::string::npos)
            throw std::invalid_argument("refusing DROP: " + q);
        if (host == "db-down")
            throw std::runtime_error("connection reset by peer");
        std::cout << "      query ok: " << q << "\n";
    }
};

/* ---- layer 2: the driver. Adds context, RETHROWS. ---- */
void runQuery(const std::string &host, const std::string &q) {
    Connection c(host);
    try {
        c.query(q);
    }
    catch (const std::exception &e) {
        /* local work: record what happened HERE */
        std::cout << "      [driver] on host " << host
                  << ": " << e.what() << "\n";
        throw;   /* the driver cannot decide policy — pass up */
    }
    /* ~Connection runs on BOTH paths */
}

/* ---- layer 3: the application. Decides what to DO. ---- */
int main() {
    struct Job { const char *host; const char *sql; };
    std::vector<Job> jobs = {
        {"db-primary", "SELECT * FROM students"},
        {"db-primary", "DROP TABLE students"},
        {"db-down",    "SELECT count(*)"},
    };

    for (const auto &j : jobs) {
        std::cout << "  job: " << j.sql << " @ " << j.host << "\n";
        try {
            runQuery(j.host, j.sql);
            std::cout << "    result: success\n";
        }
        catch (const std::invalid_argument &e) {
            /* policy: a bad query is OUR bug, do not retry */
            std::cout << "    result: rejected, not retrying\n";
        }
        catch (const std::runtime_error &e) {
            /* policy: a transport failure — retry elsewhere */
            std::cout << "    result: transient, retrying on "
                      << "db-replica\n";
            try { runQuery("db-replica", j.sql); }
            catch (const std::exception &e2) {
                std::cout << "    retry also failed\n";
            }
        }
    }
    return 0;
}
Output:
  job: SELECT * FROM students @ db-primary
      + connected to db-primary
      query ok: SELECT * FROM students
      - closed db-primary
    result: success
  job: DROP TABLE students @ db-primary
      + connected to db-primary
      [driver] on host db-primary: refusing DROP: DROP TABLE students
      - closed db-primary
    result: rejected, not retrying
  job: SELECT count(*) @ db-down
      + connected to db-down
      [driver] on host db-down: connection reset by peer
      - closed db-down
    result: transient, retrying on db-replica
      + connected to db-replica
      query ok: SELECT count(*)
      - closed db-replica
    result: success

Three things this demonstrates together. 1. THE DESTRUCTOR ALWAYS RAN. "- closed <host>" appears on every path — success, rejection, and failure. The Connection is released by RAII during unwinding, before the application's handler executes. No cleanup code exists anywhere in runQuery. 2. THE DRIVER ADDED CONTEXT WITHOUT DECIDING. It knows the host name, which the low-level query() does not, so it logs that and rethrows. It does NOT decide whether to retry, because that is a business decision it cannot make. 3. THE APPLICATION APPLIED DIFFERENT POLICIES to different types: invalid_argument → our bug, do not retry runtime_error → transient, retry on a replica That distinction is only possible because `throw;` preserved the exact type. With `throw e;` both would arrive as std::exception and the retry logic could not fire. Note the retry succeeded — "result: success" after the retry — because db-replica is not db-down. THE PRINCIPLE, worth stating in an exam: catch where you have INFORMATION, handle where you have RESPONSIBILITY. When those are different places, log and rethrow.

Function-try-blocks and rethrowing from a constructor

A constructor's INITIALISER LIST can throw, and a normal try block inside the body cannot catch that — the body has not started. The solution is a FUNCTION-TRY-BLOCK: class Widget { Resource r; public: Widget(int n) try : r(n) { /* try covers the init list */ /* constructor body */ } catch (const std::exception &e) { log(e.what()); throw; /* MANDATORY — see below */ } }; THE HARD RULE: a catch handler on a constructor's function-try-block MUST exit by throwing. You may not "swallow" the exception and return normally, because the object was never fully constructed — there is nothing valid to hand back. If you write no throw, the compiler inserts an implicit `throw;` at the end of the handler. So the exception always propagates. All you can do is log it, or translate it into a different type. Members already constructed ARE destroyed before the handler runs, and you must not touch them inside it — they are gone. For DESTRUCTORS, a function-try-block may swallow the exception (destructors must not throw), which is the one place this is permitted.

ctor_try.cpp

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

class Resource {
    std::string name;
public:
    Resource(std::string n, bool fail) : name(std::move(n)) {
        if (fail) throw std::runtime_error("cannot acquire " + name);
        std::cout << "      + " << name << "\n";
    }
    ~Resource() { std::cout << "      - " << name << "\n"; }
};

class Widget {
    Resource a, b;
public:
    Widget(bool failA, bool failB)
    try : a("resA", failA), b("resB", failB) {
        std::cout << "      Widget body\n";
    }
    catch (const std::exception &e) {
        std::cout << "      [ctor handler] " << e.what() << "\n";
        /* an implicit throw; happens here even if we
           write nothing — a half-built object cannot be
           returned */
        throw std::runtime_error(std::string("Widget failed: ")
                                 + e.what());
    }
    ~Widget() { std::cout << "      ~Widget\n"; }
};

int main() {
    std::cout << "  case 1: both succeed\n";
    { Widget w(false, false); }

    std::cout << "  case 2: second resource fails\n";
    try { Widget w(false, true); }
    catch (const std::exception &e) {
        std::cout << "    main caught: " << e.what() << "\n";
    }

    std::cout << "  case 3: first resource fails\n";
    try { Widget w(true, false); }
    catch (const std::exception &e) {
        std::cout << "    main caught: " << e.what() << "\n";
    }
    return 0;
}
Output:
  case 1: both succeed
      + resA
      + resB
      Widget body
      ~Widget
      - resB
      - resA
  case 2: second resource fails
      + resA
      - resA
      [ctor handler] cannot acquire resB
    main caught: Widget failed: cannot acquire resB
  case 3: first resource fails
      [ctor handler] cannot acquire resA
    main caught: Widget failed: cannot acquire resA

Case 2 is the instructive one: + resA a constructed successfully - resA a DESTROYED before the handler ran [ctor handler] ... main caught: ... So the already-constructed member was cleaned up automatically, and by the time the handler executed it no longer existed. That is why you must not touch members inside a constructor's catch handler. Notice also that ~Widget was NEVER called in cases 2 and 3. An object whose constructor throws was never constructed, so its destructor does not run — only the destructors of members that HAD completed. This is the rule that makes RAII safe: a half-built object cannot leak, because every completed sub-object is destroyed and nothing else exists. Case 3 shows resA failing, so nothing was constructed and nothing needed destroying. And in case 1, the order is: ~Widget body first, then members in REVERSE declaration order (resB before resA) — the standard destruction order from the inheritance topic.

🌍 Go further: C++11's std::exception_ptr lets you store an exception and rethrow it elsewhere — even on a different thread. That is exactly how std::future works: an exception thrown inside std::async is captured, carried across the thread boundary, and rethrown when you call future.get(). Without it, an exception on a worker thread would just terminate the program. std::current_exception() captures, std::rethrow_exception(p) replays. Search "std::exception_ptr across threads" — it is the mechanism behind every concurrent error report in modern C++.

💡 Exam angle: the throw; versus throw e; distinction is the core question — a bare throw rethrows the original object preserving its dynamic type, while throw e; throws a sliced copy and loses derived data. Be ready to show a program where the outer specific handler stops matching. State that a bare throw outside any catch calls std::terminate. Know the log-and-rethrow pattern: catch where you have information, handle where you have responsibility. The constructor function-try-block rule (the handler must exit by throwing) is a good advanced point.

Syllabus points

Re-throwing an exception

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.