Exception Handling

A throw is a jump, but not a jump the compiler can resolve. Its target depends on the dynamic call chain: which handler catches depends on who called this function, which is not knowable when the function is compiled. That single fact is what makes exceptions an implementation problem rather than a syntax problem — everything else follows from needing to answer a question at run time that is normally answered at compile time.

The second promise is cleanup. Every frame between the throw and the handler is destroyed, and everything with a destructor or a finally in those frames must run, in reverse construction order, before the handler executes. A mechanism that only jumped would leak every file handle, lock and buffer in between.

The third, easy to overlook, is that the intervening functions did not agree to any of this. A function that neither throws nor catches still has to have its locals cleaned up when an exception passes through it. So the obligation is not on the try and the throw; it is on every function in the program, which is why exceptions affect code generation everywhere and not just where they are mentioned.

The old approach — setjmp/longjmp, or SJLJ — makes the dynamic chain explicit at run time. Entering a try pushes a record onto a thread-local list saying "if something is thrown here, come back to this point"; leaving pops it. A throw walks the list, finds the innermost matching entry, and does a longjmp to it. Finding the handler is then trivial, because the list is exactly the answer.

The cost is that every try entry and exit executes instructions, whether or not anything is thrown, and the saved context inhibits optimization around it: values must be in memory rather than registers at the point where a longjmp could land. A program that never throws pays on every entry to every guarded region, forever.

The modern approach — table-driven, often called zero-cost — inverts this. Nothing is emitted at try entry at all. Instead the compiler records, in a separate section of the binary, a table saying for each range of instruction addresses: which cleanups are live, and which handlers apply. When a throw happens, the runtime walks the physical stack, and for each return address it looks the address up in the tables to discover what to do. The information that SJLJ maintained at run time is precomputed at compile time and indexed by program counter.

The trade is exact and worth memorising: SJLJ pays on entry and throws cheaply; table-driven pays nothing on entry and throws expensively, because a throw now involves a table lookup and an indirect call per frame. Which is better depends entirely on whether exceptions are exceptional — and the fact that mainstream toolchains all chose the second is a statement about how they expect the feature to be used.

Under the table-driven scheme the generated code for a try block looks almost exactly like the code without it. The difference is in the CFG: every call inside a try region becomes a two-way branch — normal return, or *unwind* to a landing pad. The landing pad is real code, emitted in a cold section, containing the cleanups for that region and the dispatch to the matching catch.

LLVM makes this explicit in the IR, which is the clearest way to see it. An ordinary call is call; a call inside a try is invoke, which names two successor blocks. The landing pad block starts with a landingpad instruction listing the types it is prepared to catch. Nothing about this costs anything on the normal path — the invoke compiles to the same call instruction — but the CFG edge is there, and the optimizer has to respect it.

That edge is where the "zero-cost" claim gets its asterisks. The optimizer cannot move a side effect across a call that may throw, because there is now a path out at that point. It cannot always keep a value in a register across it, because the landing pad may need it. And every one of those calls contributes an entry to the tables, which is why binaries with exceptions enabled are meaningfully larger even when nothing ever throws.

"Zero-cost exceptions cost nothing" is true of the instruction stream on the non-throwing path and false of everything else. Three costs remain, and all three are measurable.

Binary size. The unwind tables and the language-specific data areas are real bytes in the binary, and for C++ code they are frequently in the range of ten to twenty percent of the text they describe. Cleanup code duplicated into landing pads adds more. This is why -fno-exceptions is a size optimization on embedded targets, and why it is a hard requirement in some of them.

Optimization. Every potentially-throwing call is a CFG edge out of the block, which limits code motion, forces some values to be reloadable, and complicates every analysis that walks the graph. Marking a function noexcept removes the edge and measurably improves the code around it — which is exactly why the annotation exists and why the standard library is full of it.

And the throw itself, which is not fast. Unwinding one frame means finding the frame's entry in a sorted table, decoding CFI to compute the caller's registers, calling the personality routine, and — under the Itanium ABI — doing all of it twice, once in a search phase to find the handler and again in a cleanup phase to run the destructors. Costs in the tens of microseconds for a deep stack are unremarkable. That is completely acceptable for an error path and catastrophic as a control-flow mechanism, which is the entire content of the advice not to use exceptions for expected outcomes.

Java compiles try/catch to a per-method exception table: ranges of bytecode indices, a handler index, and a type. The JIT then turns that into the same kind of address-indexed table a native compiler would emit. finally was historically compiled by duplicating the block into every exit path — including the exceptional one — which is why a finally in a method with many returns produces more bytecode than it looks like it should.

Go has no exceptions and has panic/recover with defer, which needs the same mechanism for the same reason: a panic must run every deferred call on the way out. Early Go implementations kept a linked list of deferred calls at run time, closer to the SJLJ shape; later versions moved to open-coded defers with a bitmask and a table, which is the table-driven design applied to cleanups rather than handlers.

Rust panics unwind through the platform unwinder, running Drop for everything in between, unless the program is built with panic=abort — in which case the tables disappear, the binary shrinks, and a panic terminates the process. That the choice is a build flag rather than a language property is the clearest available demonstration that exception handling is an implementation strategy with a bill attached.

And error-code returns, the alternative that never went away, put the same information in the normal path: every call site tests, every function threads the failure outward, and nothing is hidden. It costs a branch per call on the happy path and it costs nothing in tables — the exact inverse of the table-driven trade, which is why the argument between the two has lasted forty years.