Handling Uncaught & Unexpected Exceptions

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

Handling Uncaught and Unexpected Exceptions

What happens when nothing catches — std::terminate, set_terminate, and the last chance to leave a diagnostic behind.

🌍 Where this lives: every crash report you have ever seen comes from this machinery. When a mobile app crashes and offers to "send a report", a terminate handler captured the state first. Crashpad and Breakpad — the crash reporters inside Chrome, Firefox and most games — install handlers exactly like the ones below to write a minidump before the process dies. The difference between a bug report saying "it crashed" and one saying "uncaught std::out_of_range in loadConfig, line 84" is a handler someone installed in main. Search "Google Breakpad crash reporting".

When `std::terminate` is called

std::terminate() is invoked when the exception mechanism cannot proceed. The full list of triggers: 1. an exception is thrown and NO handler matches 2. an exception escapes a `noexcept` function 3. an exception escapes a DESTRUCTOR during unwinding (two exceptions in flight at once) 4. an exception escapes a THREAD's entry function 5. a bare `throw;` with no exception being handled 6. an exception escapes main's initialisation or a static object's constructor/destructor 7. an exception escapes a constructor's function-try-block handler that does not itself throw (implicit rethrow with nowhere to go) WHAT IT DOES: · calls the current TERMINATE HANDLER, which defaults to std::abort() · abort() raises SIGABRT, so the process dies and may produce a core dump THE CRITICAL DETAIL: whether the stack is UNWOUND first is IMPLEMENTATION-DEFINED, and in practice it usually is NOT. So on the terminate path: · local destructors do NOT run · files are not closed or flushed · mutexes stay locked · buffered stdout may be lost That is why an uncaught exception can lose the very log message that would have explained it. std::terminate_handler std::set_terminate(std::terminate_handler); installs your own; returns the previous one std::get_terminate(); /* C++11: read the current one */ YOUR HANDLER MUST NOT RETURN. If it does, the behaviour is undefined — end it with abort(), _Exit(), or exit(). HISTORICAL: std::unexpected() and std::set_unexpected() belonged to the old throw() specification mechanism. They were deprecated in C++11 and REMOVED in C++17. Recognise them; do not use them.

terminate_handler.cpp

#include <iostream>
#include <exception>
#include <stdexcept>
#include <cstdlib>
#include <string>

/* A diagnostic handler. It runs when nothing caught the
   exception, and it must NOT return. */
void crashReporter() {
    std::cerr << "\n  ===== CRASH REPORT =====\n";

    /* recover the in-flight exception, if any (C++11) */
    if (std::exception_ptr p = std::current_exception()) {
        try { std::rethrow_exception(p); }
        catch (const std::exception &e) {
            std::cerr << "  type   : std::exception subclass\n"
                      << "  what() : " << e.what() << "\n";
        }
        catch (int n) {
            std::cerr << "  type   : int\n  value  : " << n << "\n";
        }
        catch (...) {
            std::cerr << "  type   : unrecognised\n";
        }
    } else {
        std::cerr << "  no exception in flight "
                     "(terminate called directly)\n";
    }

    std::cerr << "  action : flushing logs, aborting\n"
              << "  ========================\n";
    std::cerr.flush();
    std::abort();          /* must not return */
}

struct Tracked {
    std::string name;
    Tracked(std::string n) : name(std::move(n)) {
        std::cout << "    +" << name << "\n";
    }
    ~Tracked() { std::cout << "    -" << name << "\n"; }
};

void deep() {
    Tracked t("deep-local");
    throw std::out_of_range("index 42 out of range");
}

int main() {
    std::set_terminate(crashReporter);

    std::cout << "  --- caught properly: destructors run ---\n";
    try { deep(); }
    catch (const std::exception &e) {
        std::cout << "    caught: " << e.what() << "\n";
    }

    std::cout << "  --- now UNCAUGHT ---\n";
    Tracked outer("main-local");
    deep();                /* nothing catches this */
    std::cout << "  unreachable\n";
}
Output:
  --- caught properly: destructors run ---
    +deep-local
    -deep-local
    caught: index 42 out of range
  --- now UNCAUGHT ---
    +main-local
    +deep-local

  ===== CRASH REPORT =====
  type   : std::exception subclass
  what() : index 42 out of range
  action : flushing logs, aborting
  ========================
Abort trap: 6

Compare the two halves line by line — this is the single most important observation in the topic. CAUGHT PATH +deep-local -deep-local ← the destructor RAN caught: ... UNCAUGHT PATH +main-local +deep-local ===== CRASH REPORT ===== ← NEITHER destructor ran No "-deep-local", no "-main-local". The stack was not unwound. If Tracked had held an open file, unsaved data, or a locked mutex, all of it would be lost or left dangling. Yet the handler still identified the exception, because std::current_exception() returns a pointer to the exception object itself, which exists independently of the stack. The rethrow-and-recatch idiom then extracts the type and message. WHAT THIS BUYS YOU IN PRACTICE: without a handler, the default output is roughly terminate called after throwing an instance of 'std::out_of_range' what(): index 42 out of range Aborted which is better than nothing but has no application context. A real handler adds the version, the build id, the current operation, a stack trace, and flushes your own log files before dying.

The lost destructors are the reason a top-level try/catch in main is worth writing even when it only logs and returns. Catching means the stack is unwound, so files flush and locks release — a terminate handler can report the problem but cannot undo the fact that cleanup was skipped.

Worked example — a robust `main`

robust_main.cpp

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

/* exit codes a shell script can act on */
enum ExitCode {
    OK = 0, BAD_INPUT = 2, IO_FAILURE = 3,
    OUT_OF_MEMORY = 4, INTERNAL_BUG = 70, UNKNOWN = 99
};

void lastResort() {
    std::cerr << "  [terminate] an exception escaped every "
                 "handler\n";
    if (auto p = std::current_exception()) {
        try { std::rethrow_exception(p); }
        catch (const std::exception &e) {
            std::cerr << "  [terminate] " << e.what() << "\n";
        }
        catch (...) { std::cerr << "  [terminate] non-standard type\n"; }
    }
    std::cerr.flush();
    std::_Exit(UNKNOWN);      /* no destructors, no atexit */
}

void runJob(int job) {
    switch (job) {
        case 0: std::cout << "    job 0 completed\n"; break;
        case 1: throw std::invalid_argument("empty student name");
        case 2: throw std::ios_base::failure("cannot open marks.dat");
        case 3: throw std::bad_alloc();
        case 4: throw std::logic_error("impossible branch reached");
        case 5: throw std::string("a non-standard exception type");
    }
}

/* THE STANDARD ROBUST MAIN: one try, ordered handlers,
   a meaningful exit code for each class of failure */
int main() {
    std::set_terminate(lastResort);

    for (int job = 0; job <= 5; job++) {
        std::cout << "  job " << job << ":\n";
        try {
            runJob(job);
            std::cout << "    exit code would be " << OK << "\n";
        }
        catch (const std::invalid_argument &e) {
            std::cerr << "    input error: " << e.what()
                      << "  -> exit " << BAD_INPUT << "\n";
        }
        catch (const std::ios_base::failure &e) {
            std::cerr << "    I/O error: " << e.what()
                      << "  -> exit " << IO_FAILURE << "\n";
        }
        catch (const std::bad_alloc &) {
            std::cerr << "    out of memory  -> exit "
                      << OUT_OF_MEMORY << "\n";
        }
        catch (const std::logic_error &e) {
            std::cerr << "    INTERNAL BUG: " << e.what()
                      << "  -> exit " << INTERNAL_BUG << "\n";
        }
        catch (const std::exception &e) {
            std::cerr << "    unclassified: " << e.what()
                      << "  -> exit " << UNKNOWN << "\n";
        }
        catch (...) {
            std::cerr << "    non-standard exception  -> exit "
                      << UNKNOWN << "\n";
        }
    }
    std::cout << "  all jobs attempted; nothing escaped\n";
    return OK;
}
Output:
  job 0:
    job 0 completed
    exit code would be 0
  job 1:
    input error: empty student name  -> exit 2
  job 2:
    I/O error: cannot open marks.dat  -> exit 3
  job 3:
    out of memory  -> exit 4
  job 4:
    INTERNAL BUG: impossible branch reached  -> exit 70
  job 5:
    non-standard exception  -> exit 99
  all jobs attempted; nothing escaped

The structure of that main is worth adopting as a template. 1. set_terminate FIRST, so even a failure during setup is reported 2. handlers ordered most-derived to least-derived 3. a DISTINCT exit code per failure class, so calling scripts can react: if ./prog; then ... elif [ $? -eq 3 ]; then # I/O — retry elif [ $? -eq 70 ]; then # our bug — page someone 4. catch(...) LAST as the genuine safety net 5. the terminate handler as the layer below even that Note the deliberate distinction between logic_error (exit 70, "INTERNAL BUG") and everything else. A logic_error means the program violated its own invariant — that is a defect to fix in code, not a condition to handle. Separating it in the exit code makes it visible in monitoring instead of being lumped in with ordinary failures. Exit code 70 is not arbitrary: it is EX_SOFTWARE from sysexits.h, a BSD convention many tools follow. And note std::_Exit in the terminate handler rather than exit(): exit() runs atexit handlers and destroys static objects, which is unsafe when the program state is already broken. _Exit skips all of it.

The two-exceptions-at-once rule

double_throw.cpp

#include <iostream>
#include <stdexcept>
#include <exception>

/* A destructor that throws DURING unwinding = terminate */
struct Dangerous {
    ~Dangerous() noexcept(false) {
        std::cout << "    ~Dangerous throwing\n";
        throw std::runtime_error("from a destructor");
    }
};

/* THE CORRECT PATTERN: a destructor swallows its own
   exceptions rather than letting them escape */
struct Safe {
    ~Safe() {
        try {
            throw std::runtime_error("internal cleanup failure");
        }
        catch (...) {
            std::cout << "    ~Safe swallowed its own error\n";
        }
    }
};

int main() {
    std::cout << "  1. Safe destructor during unwinding:\n";
    try {
        Safe s;
        throw std::logic_error("the original exception");
    }
    catch (const std::exception &e) {
        std::cout << "    caught: " << e.what() << "\n";
    }

    std::cout << "  2. uncaught_exceptions() lets a destructor "
                 "detect unwinding:\n";
    std::cout << "    outside any throw: "
              << std::uncaught_exceptions() << "\n";
    try {
        struct Probe {
            ~Probe() {
                std::cout << "    inside unwinding: "
                          << std::uncaught_exceptions() << "\n";
            }
        } p;
        throw std::runtime_error("probe");
    } catch (...) { }

    std::cout << "  3. a throwing destructor during unwinding "
                 "would call terminate\n";
    /* try { Dangerous d; throw std::logic_error("first"); }
       catch (...) { }
       → terminate called: two exceptions in flight       */
    std::cout << "     (commented out — it aborts the program)\n";
    return 0;
}
Output:
  1. Safe destructor during unwinding:
    ~Safe swallowed its own error
    caught: the original exception
  2. uncaught_exceptions() lets a destructor detect unwinding:
    outside any throw: 0
    inside unwinding: 1
  3. a throwing destructor during unwinding would call terminate
     (commented out — it aborts the program)

WHY TWO EXCEPTIONS CANNOT COEXIST: the runtime tracks exactly one exception being propagated. If a destructor throws while unwinding is already in progress, there is no defined way to decide which exception wins — so the standard calls std::terminate. That is the reason for the rule you have seen throughout this section: DESTRUCTORS MUST NOT THROW. Since C++11 they are implicitly noexcept, so a throw from one terminates the program unless you explicitly write noexcept(false). Case 1 shows the correct pattern: ~Safe caught its own exception internally, so the ORIGINAL logic_error continued propagating undisturbed and was caught normally. Case 2 shows std::uncaught_exceptions() (C++17), which returns how many exceptions are currently being propagated. It returned 0 normally and 1 during unwinding — so a destructor CAN detect whether it is being called because of an exception, and behave differently: ~Transaction() { if (std::uncaught_exceptions() > 0) rollback(); else commit(); } That is the ScopeGuard / scope_success pattern, and it is the intended use of the function.

🌍 Go further: a terminate handler tells you what was thrown but not where it came from. C++23 finally added <stacktrace> so you can capture std::stacktrace::current() inside the handler and print the actual call chain — something that previously required platform-specific code (backtrace() on Linux, CaptureStackBackTrace on Windows) or a library like Boost.Stacktrace. Combined with the crash reporter above, that turns "uncaught std::out_of_range" into a filename and line number. Search "C++23 stacktrace library" and "Boost.Stacktrace terminate handler".

💡 Exam angle: list the triggers for std::terminate — no matching handler, an exception escaping a noexcept function, a destructor throwing during unwinding, a thread function letting one escape, and a bare throw; with nothing in flight. The highest-value point is that terminate may not unwind the stack, so destructors do not run — which is why a top-level catch in main matters. Know std::set_terminate and that the handler must not return. Explain the two-exceptions rule as the reason destructors must not throw, and mention that std::unexpected was removed in C++17 along with dynamic exception specifications.

Syllabus points

terminate(), unexpected()

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.