Why do 52% of developers (as surveyed by isocpp) disable exceptions from all or part of their codebases? Why are so many returning to error codes, or looking at more modern alternatives, such as ADT-based error handling (optional, expected etc)? Can we do better? Will we ever re-unify those who eschew std C++ by banning exceptions?
We'll take a tour of the past, present and future of error handling in C++ - including a number of proposals currently in-flight, and the thinking behind them. Along the way will attempt to put a score on all the trade-offs of the different approaches we encounter along the way to see how they stack up.
YOU MAY ALSO LIKE:
- Dawn of a New Error (SkillsCast recorded in October 2019)
- Lightbend Akka for Scala - Professional (in London on 11th - 12th November 2019)
- Advanced Scala with Dick Wall (in London on 9th - 11th December 2019)
- F# eXchange 2020 (in London on 2nd - 3rd April 2020)
- London Unreal Engine Meetup #33 (in London on 21st November 2019)
- Testing and UB (in London on 21st November 2019)
- Type Punning in Modern C++ (SkillsCast recorded in September 2019)
Option(al) Is Not a Failure
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.