Exception Specification for Function

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

Exception Specification for a Function

Declaring what a function may throw — the old throw() lists, why they failed, and noexcept which replaced them.

🌍 Where this lives: noexcept looks like documentation and is actually a performance switch. std::vector inspects whether your move constructor is noexcept to decide, during reallocation, whether it can move your elements or must copy them — because if a move could throw halfway through, the vector would be left in a broken state with no way to recover. So a missing noexcept on a move constructor silently turns every vector growth from pointer swaps into full deep copies. This is one of the few one-word changes that measurably alters real program speed. Search "noexcept move constructor vector reallocation".

The deprecated dynamic exception specification

C++98 let you list the types a function might throw: void f() throw(std::runtime_error); /* only this */ void g() throw(std::bad_alloc, MyError); /* either */ void h() throw(); /* NOTHING */ void i(); /* anything */ IT SOUNDED USEFUL AND WAS A FAILURE. Four reasons: 1. NOT CHECKED AT COMPILE TIME. Unlike Java's `throws`, the compiler does not verify that f only throws runtime_error. It merely inserts a RUNTIME check. 2. VIOLATION CALLS std::unexpected(), which by default calls std::terminate(). So breaking the promise kills the program instead of producing a compile error — the worst possible time to find out. 3. IT MADE CODE SLOWER. The compiler had to wrap the function in a check, so the specification cost performance rather than enabling optimisation. 4. IT DID NOT COMPOSE. A template cannot know what its type parameter's operations might throw, so generic code could not use it at all. STATUS: · DEPRECATED in C++11 · REMOVED in C++17 — the syntax is a compile error, except for throw() which was kept as a synonym for noexcept · REMOVED entirely in C++20 Do not write them. Recognise them in old code and in exam questions about C++ history.

`noexcept` — the replacement

void f() noexcept; /* promises: never throws */ void g() noexcept(true); /* same thing */ void h() noexcept(false); /* may throw — the default */ void i(); /* may throw */ /* CONDITIONAL: noexcept only if some expression is */ template <typename T> void swap(T &a, T &b) noexcept(std::is_nothrow_move_constructible_v<T> && std::is_nothrow_move_assignable_v<T>); WHAT HAPPENS ON VIOLATION: an exception escaping a noexcept function calls std::terminate() IMMEDIATELY — with no stack unwinding at all. Destructors do not run. That sounds harsh, and it is the point: noexcept is a PROMISE, not a filter. You are telling the compiler it may assume no exception can leave, and that assumption is what enables the optimisation. WHY IT IS FASTER THAN throw(): throw() → the compiler ADDS a runtime check noexcept → the compiler REMOVES the unwind machinery. No exception tables, no landing pads, and the caller needs no cleanup path. THE noexcept OPERATOR — a compile-time query, not a specifier: bool b = noexcept(expr); /* true if expr cannot throw. expr is NOT evaluated. */ noexcept(1 + 2) → true noexcept(new int) → false (may throw bad_alloc) noexcept(someNoexceptFn()) → true Note the same keyword does two jobs: as a SPECIFIER after a function's parameter list, and as an OPERATOR taking an expression. Confusing them is a common exam trap. IMPLICITLY noexcept, whether you write it or not: · destructors · defaulted move/copy constructors and assignments, IF all their members' corresponding operations are noexcept · deallocation functions (operator delete)

noexcept_basics.cpp

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

int  safeAdd(int a, int b) noexcept { return a + b; }
int  mayThrow(int a)                { if (a < 0)
                                          throw std::domain_error("neg");
                                      return a * 2; }
int* allocate(int n)                { return new int[n]; }

/* conditional noexcept: this is noexcept only when T's
   operations are */
template <typename T>
void mySwap(T &a, T &b)
    noexcept(std::is_nothrow_move_constructible_v<T> &&
             std::is_nothrow_move_assignable_v<T>)
{
    T t = std::move(a); a = std::move(b); b = std::move(t);
}

struct Throwy {
    Throwy() = default;
    Throwy(Throwy&&) { }                 /* NOT noexcept */
    Throwy& operator=(Throwy&&) { return *this; }
};

int main() {
    std::cout << std::boolalpha;

    /* the noexcept OPERATOR queries at compile time */
    std::cout << "  noexcept(1 + 2)          = "
              << noexcept(1 + 2) << "\n";
    std::cout << "  noexcept(safeAdd(1,2))   = "
              << noexcept(safeAdd(1,2)) << "\n";
    std::cout << "  noexcept(mayThrow(1))    = "
              << noexcept(mayThrow(1)) << "\n";
    std::cout << "  noexcept(allocate(10))   = "
              << noexcept(allocate(10)) << "\n";
    std::cout << "  noexcept(new int)        = "
              << noexcept(new int) << "\n";

    /* conditional noexcept resolves per type */
    int i = 1, j = 2;
    std::string s1 = "a", s2 = "b";
    Throwy t1, t2;
    std::cout << "  mySwap<int>     noexcept? "
              << noexcept(mySwap(i, j)) << "\n";
    std::cout << "  mySwap<string>  noexcept? "
              << noexcept(mySwap(s1, s2)) << "\n";
    std::cout << "  mySwap<Throwy>  noexcept? "
              << noexcept(mySwap(t1, t2)) << "\n";

    /* type traits used by the standard library */
    std::cout << "  is_nothrow_move_constructible<string> = "
              << std::is_nothrow_move_constructible_v<std::string>
              << "\n";
    std::cout << "  is_nothrow_move_constructible<Throwy> = "
              << std::is_nothrow_move_constructible_v<Throwy>
              << "\n";
    return 0;
}
Output:
  noexcept(1 + 2)          = true
  noexcept(safeAdd(1,2))   = true
  noexcept(mayThrow(1))    = false
  noexcept(allocate(10))   = false
  noexcept(new int)        = false
  mySwap<int>     noexcept? true
  mySwap<string>  noexcept? true
  mySwap<Throwy>  noexcept? false
  is_nothrow_move_constructible<string> = true
  is_nothrow_move_constructible<Throwy> = false

Each line explains itself once you know what is being asked: noexcept(1 + 2) → integer arithmetic cannot throw noexcept(safeAdd(...)) → declared noexcept, so true noexcept(mayThrow(1)) → NOT declared noexcept, so false. Note the compiler does NOT analyse the body — the answer comes from the DECLARATION alone. A function that provably never throws is still `false` unless you say noexcept. noexcept(new int) → operator new can throw bad_alloc mySwap<int> → int's move operations are trivial and noexcept → the whole swap is noexcept mySwap<string> → std::string's move ctor is noexcept (it steals a pointer), so true mySwap<Throwy> → Throwy's move ctor is not marked noexcept, so the condition is false and mySwap is not noexcept for it That is CONDITIONAL noexcept doing its job: one template, and its exception guarantee is computed per instantiation. This is exactly how std::swap, std::vector and std::pair declare theirs, and it is why generic code can make accurate promises about types it has never seen.

The key limitation: noexcept is a declaration, not an analysis. The compiler never inspects your function body to decide. noexcept(mayThrow(1)) is false even for arguments that provably cannot throw, and conversely, marking a throwing function noexcept compiles fine — and terminates the program at runtime.

Worked example — the vector reallocation consequence

vector_noexcept.cpp

#include <iostream>
#include <vector>
#include <string>
#include <type_traits>

/* Two identical classes. The ONLY difference is one keyword
   on the move constructor. */
struct Fast {
    std::string data;
    int id;
    Fast(int i) : data(1000, 'x'), id(i) {}
    Fast(Fast &&o) noexcept
        : data(std::move(o.data)), id(o.id) { ++moves; }
    Fast(const Fast &o) : data(o.data), id(o.id) { ++copies; }
    Fast& operator=(Fast&&) noexcept = default;
    Fast& operator=(const Fast&) = default;
    static int moves, copies;
};
int Fast::moves = 0, Fast::copies = 0;

struct Slow {
    std::string data;
    int id;
    Slow(int i) : data(1000, 'x'), id(i) {}
    Slow(Slow &&o)                        /* NO noexcept */
        : data(std::move(o.data)), id(o.id) { ++moves; }
    Slow(const Slow &o) : data(o.data), id(o.id) { ++copies; }
    static int moves, copies;
};
int Slow::moves = 0, Slow::copies = 0;

int main() {
    std::cout << std::boolalpha;
    std::cout << "  Fast move is noexcept: "
              << std::is_nothrow_move_constructible_v<Fast> << "\n";
    std::cout << "  Slow move is noexcept: "
              << std::is_nothrow_move_constructible_v<Slow> << "\n\n";

    /* force several reallocations by pushing without
       reserving */
    {
        std::vector<Fast> v;
        for (int i = 0; i < 20; i++) v.push_back(Fast(i));
        std::cout << "  Fast: " << Fast::moves << " moves, "
                  << Fast::copies << " copies\n";
    }
    {
        std::vector<Slow> v;
        for (int i = 0; i < 20; i++) v.push_back(Slow(i));
        std::cout << "  Slow: " << Slow::moves << " moves, "
                  << Slow::copies << " copies\n";
    }

    std::cout << "\n  Each copy duplicates a 1000-char string;\n"
              << "  each move just steals a pointer.\n";
    return 0;
}
Output:
  Fast move is noexcept: true
  Slow move is noexcept: false

  Fast: 51 moves, 0 copies
  Slow: 20 moves, 31 copies

  Each copy duplicates a 1000-char string;
  each move just steals a pointer.

The numbers are the whole argument for noexcept. Both vectors did the same work: 20 push_backs with growth 1 → 2 → 4 → 8 → 16 → 32, so 5 reallocations moving 1 + 2 + 4 + 8 + 16 = 31 existing elements. Fast: 51 moves, 0 copies 20 moves for the push_back temporaries + 31 moves during reallocation = 51 moves, ZERO copies Slow: 20 moves, 31 copies 20 moves for the temporaries (push_back can still move — it is not the risky operation) + 31 COPIES during reallocation WHY. During reallocation vector must transfer n existing elements into new storage. If a MOVE could throw partway through, the old elements have already been gutted and the new array is incomplete — the vector cannot restore its previous state, so the STRONG exception guarantee is broken. So vector checks is_nothrow_move_constructible: · true → move each element (fast, and safe because it cannot fail) · false → COPY each element, keeping the originals intact until the copy fully succeeds, then destroy them 31 copies of a 1000-character string is roughly 31,000 bytes memcpy'd plus 31 heap allocations, versus 31 pointer steals. One keyword. THE PRACTICAL RULE: always mark move constructors and move assignment noexcept — and you genuinely can, because a correct move only transfers pointers and never allocates.

Where to use it, and where not to

MARK noexcept — you can honestly promise it, and it helps: · MOVE constructors and move assignment (the big win) · SWAP functions · DESTRUCTORS (already implicit, but be aware) · simple accessors and getters · arithmetic and comparison on built-in types · anything a container will call during reallocation DO NOT MARK noexcept: · anything that ALLOCATES (new, push_back, string concatenation) — bad_alloc is always possible · anything calling code you do not control · a function whose implementation may change to throw later — REMOVING noexcept from a published API is a breaking change for callers who relied on it · when you are not certain. The default (may throw) is always safe; a false promise terminates the program. THE ASYMMETRY WORTH KNOWING: adding noexcept to an existing function is safe for callers; REMOVING it is not, because generic code may have selected a different algorithm based on it. So do not add it speculatively to a public interface. CHECKING YOURSELF — the type traits, all in <type_traits>: std::is_nothrow_move_constructible_v<T> std::is_nothrow_move_assignable_v<T> std::is_nothrow_copy_constructible_v<T> std::is_nothrow_destructible_v<T> std::is_nothrow_swappable_v<T> These are what the standard library queries, and what you should query in your own conditional noexcept expressions.

violation.cpp

#include <iostream>
#include <stdexcept>

struct Loud {
    ~Loud() { std::cout << "  ~Loud ran\n"; }
};

/* A LIE: this is marked noexcept but throws. It compiles
   with only a warning. */
void liar() noexcept {
    Loud l;
    throw std::runtime_error("broke the promise");
}

int main() {
    std::cout << "  calling a noexcept function that throws:\n";
    try {
        liar();
    }
    catch (const std::exception &e) {
        std::cout << "  NEVER REACHED: " << e.what() << "\n";
    }
    std::cout << "  also never reached\n";
    return 0;
}
Output:
  calling a noexcept function that throws:
terminate called after throwing an instance of 'std::runtime_error'
  what():  broke the promise
Abort trap: 6

(g++ warning at compile time:
 warning: 'throw' will always call 'terminate' [-Wterminate])

Three things this proves: 1. THE catch DID NOT RUN. A noexcept violation does not propagate the exception — it calls std::terminate directly. The handler in main is irrelevant. 2. ~Loud DID NOT RUN. No unwinding happens, so local destructors are skipped. Files stay open, locks stay held, buffers are unflushed. 3. THE COMPILER WARNED. g++ emits -Wterminate for a throw that provably reaches a noexcept boundary. It is a warning, not an error, so the code compiles — which is why the warning is worth enabling and reading. The lesson: noexcept is a promise the compiler OPTIMISES AGAINST and does not verify. Making a false promise converts a catchable error into an immediate, undebuggable abort. Only write it when it is true.

🌍 Go further: the failure of C++98's throw() lists is a genuinely instructive piece of language-design history, because Java made the opposite choice and does check its throws clauses at compile time. Two decades of experience produced a broad consensus that Java's checked exceptions were also a mistake — they force callers to write meaningless wrappers, and they break when interfaces are extended. C# deliberately omitted them; Kotlin removed them from Java. Search "checked exceptions considered harmful" and "why C++ removed exception specifications" — the two stories converge on the same conclusion from different directions.

💡 Exam angle: explain that dynamic exception specifications (throw(TypeList)) were deprecated in C++11 and removed in C++17, and give the reasons — not compile-time checked, violation calls terminate, and they made code slower. Then contrast with noexcept: it lets the compiler omit unwind machinery rather than add a check. State that a violation calls std::terminate without unwinding, so destructors do not run. Know the two roles of the keyword (specifier and operator) and that move constructors should always be marked noexcept — with the vector reallocation reason as the strongest supporting detail.

Syllabus points

Specifying exceptions a function may 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.