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:
- Functional Concurrency in .NET with C# & F# with Riccardo Terrell (in London on 20th - 21st September 2018)
- CloudNative London 2018 (in London on 26th - 28th September 2018)
- Well-Typed's Guide to the Haskell Type System (in London on 10th October 2018)
- Well-Typed's Guide to Haskell Performance and Optimization (in London on 15th - 16th October 2018)
Option(al) Is Not a Failure
Phil is a Developer Advocate for Swift, Objective-C and C++ tools at JetBrains. Prior to that he worked in as diverse fields as: finance, agile coaching and iOS development. A long time C++ developer he also has his feet in Swift, Objective-C and F# - as well as dabbling in other languages. He is the author of several open source projects - most notably Catch: a C++-native test framework - and had the first version of the strategy board game, Risk, in the iOS app store.