Ch19.10: De-fragmenting C++

Watch This Before You Write Another throw

This chapter argued that legacy exceptions are a problem of the mechanism, not of the people using it. That argument is not new: Herb Sutter made it in 2019, in a talk that is the origin of everything this chapter taught. The talk is De-fragmenting C++: Making Exceptions and RTTI More Affordable and Usable, and it is worth the hour for two reasons: it shows the same measurements from the other side (binary size, the cost of a throw), and it presents the design that became the throws channel you have been using since Ch3.16.

The Talk

What to listen for, in the order the talk raises it:

• The two failure models and why they cannot coexist. If half of a program reports errors with return values and half with throw, the half that uses return values is not safe, because it still calls code that may unwind.
• The size numbers. Every function that might need to unwind carries frame tables; the talk counts what that costs in a real binary, which is the same mechanism Ch19.7 measured as .eh_frame and .gcc_except_table.
• The latency numbers. A throw is a stack walk, so its cost depends on how deep the stack is and how many shared objects are loaded — Ch19.8 measured about a microsecond against one nanosecond for the same error.
• Two words and a flag. The proposal at the end of the talk is exactly the ::std::error you have been catching: a domain pointer, a code, and a failure bit on the return path, so the failure path is the success path plus a branch.

After the Video

Come back to this chapter with the questions the talk leaves open, because the pages answer them concretely:

• Ch19.1 — the domain table: who writes it, what the five hooks are, and why do_to_errc is mandatory so that every error is comparable.
• Ch19.2 — what happens to the cases the proposal leaves as "uncatchable": allocation failure, size overflow, broken invariants.
• Ch19.6 — the boundary with the old mechanism, in both directions.
• Ch19.9 — how the policy of a container decides whether a failure is reported or terminates.

The rest of this book uses the mechanism the talk proposed, everywhere, without exception. Chapter 20 is the payoff: it is the reason the mechanism matters, because it is the chapter about running on targets where nothing else works.