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:
- Option(al) Is Not A Failure (SkillsCast recorded in March 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)
- Hands-on: Fractal art with Fable and WebGL (in London on 20th June 2019)
- Keynote by Dick Wall on Why API Design Matters, and Why Yours Sucks! (and mine sucks too!) (in London on 24th June 2019)
- Less Obvious Things To Do With Django's ORM (SkillsCast recorded in June 2019)
- User-First Internationalisation (SkillsCast recorded in June 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.