The Dawn of a New Error, (C++ error-handling and exceptions) - Phil Nash - CppCon 2019

—

The Dawn of a New Error, (C++ error-handling and exceptions)

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.

This presentation is the follow-up to my earlier talk, "Option(al) Is Not a Failure", where I surveyed existing error-handling approaches and score them against each other, leading up to the new proposal, p0709, "Zero-overhead deterministic exceptions" surveyed existing error-handling approaches

We'll summarise some of that background so we're all on the same page, but in this talk we're going to dig into the proposal in more depth - and look at the supporting proposals, p1028 (std::error) and p1029 ([[move relocates]]) and others. We'll also comment similar mechanisms in other languages, notably Swift, to get an idea of how it might work out in practice.
—

Phil Nash

—

*-----*
*-----*

[Dth]

RE: the question asking about RTTI at 45:00 (specifically the comment at 47:00)
Virtual functions do NOT require RTTI. Exceptions currently require RTTI so they can check the type of exceptions at catch sites and dynamic_cast the exception type to the one that is caught. These proposals remove the need for RTTI in exceptions since they don't need to use dynamic_cast anywhere in the exception handling code.

[griof]

When ever you see burritos in a software talk, you know monads are coming

[GeneralBolas]

Re: the question at 49:00 for throwing different types. It's important to realize that the whole point of `std::error` is to have a single, statically-defined exception transport mechanism. That's the whole point of the status_code_domain system: to allow the transport of "type" information *within* `std::error` itself. If you want to throw a specific "type" of error, you make a domain for it and throw it using the `std::error` mechanism. When you catch it, you can (quickly) test to see if it is of that domain and extract the data package from it efficiently.

The only downside to this methodology is that throwing types larger than an `intptr_t` requires the use of dynamic allocation. And to be honest, if you're throwing error objects bigger than that, maybe dynamic allocation is what you need to be doing.

[stercorarius]

this would be so ergonomic with ufcs too

[mozismobile]

Doesn't this all rely on C++ having usable exceptions? "deal with it at runtime" is impossible when you have literally no idea at all what "it" is, and C++ doesn't have RTTI for this case ("is this an int? No. Is it a std::vector<const char * const>? ...")
The point in Swift/Rust/etc is that errors flow upwards but are not exceptions, and are required to be informative. You really can ask "hey error, where did you come from?" and get an answer. C++ has the fatal problem that "throwing exception is just a convention" and a lot of libraries don't. Fail to vomit the right MySQL class through your code and they might as well be "raise (uint64_t) -1;" everywhere for all that you can tell (that's what their C functions return, BTW).

[WoWManiak]

Yeah, no, you had me until the virtual error_category type.