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
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.