The dawn of a new error

As a community we've tried many different ways to express, propagate and handle error conditions in our code over the years. Each seem to have different trade-offs, with none being perfect in all cases.

In C++ we adopted exceptions as the primary mechanism early on, and the standard library uses them extensively.

Yet many — 52% according to last year's Standard C++ Foundation survey — ban exceptions in all, or part, of their codebases!

Recently there has been a lot of interest in using ADTs (Algebraic Data Types) such as 'std::optional', or the proposed 'std::expected', for error handling. There are definitely advantages here, but we're still not quite there yet. Can we do better?

We start by summarizing the material from Phil's earlier talk, "Option(al) is not a failure", which surveys existing error handling approaches and scores them against each other, leading up to the new proposal, p0709r1, "Zero-overhead deterministic exceptions". We then dig into this proposal in more depth and look at the implications, considering also the supporting proposals, p1028 (std::error) and p1029 ([[move relocates]]) and others. We'll also look at experiences with similar mechanisms in other languages, notably Swift, to get an idea of how it might work out in practice.

In the end we should have a solid idea of which error handling strategy to use when, what's coming next, and how to approach code now that will play nicely in that possible future.