More than 20 years ago, exception handling was added to C++. After many years of developer experience with this feature, we now have valuable feedback on its pros and cons.
Let’s explore the opinions of some prominent figures in the C++ community and see what they think about using exceptions.
I- C++ experts
Herb Sutter, from his article:
The summary: Prefer using exceptions over error codes to report errors. Use status codes (such as return codes or errno) for errors only when exceptions cannot be used (when you don’t control all possible calling code and can’t guarantee it will be written in C++ and compiled using the same compiler and compatible compile options so that exception handling will work), and for conditions that are not errors. Use other methods, such as graceful or ungraceful termination, when recovery is not required or is impossible.
Bjarne Stroustrup, from his FAQ page:
What good can using exceptions do for me? The basic answer is: Using exceptions for error handling makes you code simpler, cleaner, and less likely to miss errors. But what’s wrong with “good old errnoand if-statements”? The basic answer is: Using those, your error handling and your normal code are closely intertwined. That way, your code gets messy and it becomes hard to ensure that you have dealt with all errors (think “spaghetti code” or a “rat’s nest of tests”).
Scott Meyers, from his “Effective C++” book:
Forty years ago, goto-laden code was considered perfectly good practice. Now we strive to write structured control flows. Twenty years ago, globally accessible data was considered perfectly good practice. Now we strive to encapsulate data. Ten years ago, writing functions without thinking about the impact of exceptions was considered good practice. Now we strive to write ex -ception-safe code.
Joel Spolsky, from his article:
People have asked why I don’t like programming with exceptions. In both Java and C++, my policy is:
1 – Never throw an exception of my own 2 – Always catch any possible exception that might be thrown by a library I’m using on the same line as it is thrown and deal with it immediately.
Andrei Alexandrescu, from his article
Writing Exception-Safe Code Is Hard
Later in the same article, he explains how using exceptions can be simplified with the scope guard idiom:
ScopeGuard is a generalization of a typical implementation of the “initialization is resource acquisition” C++ idiom. The difference is that ScopeGuard focuses only on the cleanup part — you do the resource acquisition, and ScopeGuard takes care of relinquishing the resource. (In fact, cleaning up is arguably the most important part of the idiom.)
Jon Kalb, from his website
Safe usage of exceptions is a non-trivial problem that the industry has struggled with for the better part of two decades. If you have fear, uncertainty, or doubt about exception safety or just want to see the best practices for using exceptions in C++, this session is for you. We’ll start with “What is the problem we are trying to solve?” and discuss alternatives, acknowledge the challenges associated with exception usage, and cover some well-meaning but misguided attempts at safety. I will then present a set of guidelines that are the basis for safe exception usage and solid implementation techniques, including how to transition from an exception-unsafe legacy code base.
II- Real projects
From the Boost style guide:
When should I use exceptions?
The simple answer is: “whenever the semantic and performance characteristics of exceptions are appropriate.”
From the Google style guide
On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions.
Clang
The Clang team decided not to use C++ exceptions; here’s a quote from their coding standard:
In an effort to reduce code and executable size, LLVM does not use RTTI (e.g. dynamic_cast<>) or exceptions. These two language features violate the general C++ principle of “you only pay for what you use”, causing executable bloat even if exceptions are never used in the code base, or if RTTI is never used for a class. Because of this, we turn them off globally in the code.
On the other hand, LibreOffice uses C++ exceptions.
Looking at many well-known open-source C++ projects, there is no clear preference: both approaches are widely used.
III- C++ community
If we look at forums, articles, and discussions on social media, we can identify three main viewpoints within the C++ community:
- Use them — it’s the best way to handle exceptional circumstances.
- Use them, but be very careful — they have some side effects.
- Never use them.
As a C++ developer, I’m very confused. Should I use them or not?
There is one major issue raised by all these C++ experts: writing exception-safe code is not trivial. We can classify C++ developers into four categories:
Category 1: Use C++ exceptions without caring about exception safety.
Category 2: Use C++ exceptions and are aware of exception-safety issues.
Category 3: Don’t use them, but don’t fully understand the pros and cons of exceptions.
Category 4: Don’t use them because they fully understand their drawbacks.
Developers in categories 2 and 4 know exactly what they are doing. However, those in categories 1 and 3 do not fully understand the exception mechanism, which could affect the quality of their code. Perhaps debating whether to use exceptions is the wrong question. What matters more is whether you understand the pros and cons of using them. It’s up to you to make a choice based on your specific constraints. No one can blame you if you choose one of the two approaches.