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". 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
YOU MAY ALSO LIKE:
Dawn of a New Error
Phil is the author of the test frameworks, Catch - for C++ and Objective-C, and Swordfish for Swift. As Developer Advocate at JetBrains he's involved with CLion, AppCode and ReSharper C++. More generally he's an advocate for good testing practices, TDD and using the type system and functional techniques to reduce complexity and increase correctness. He's previously worked in Finance and Mobile as well as an independent consultant and coach specialising in TDD on iOS.re.