More that 20 years ago, the exception handling was added to C++, and after many years of using this feature by the C++ developers, we have a very interesting feedback of their pros and cons.
Let’s discover the opinion of some C++ actors, and what they think about the use of the exception mechanism.
I- C++ experts
Herb Sutter From its 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 its 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 its “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 its 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.
Andrey Andrescu from its article
Writing Exception-Safe Code Is Hard
And later in the same article, he explains how using exceptions could be simplified using 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.)
Jhon Kalb from its 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 decide to not use the C++ exceptions, here’s a citation 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.
In the other side LibreOffice uses the C++ exception mechanism.
When exploring many known C++ open source projects, there’s no preferable choice. The two approaches are widely used.
III- C++ community
If we search in forums, articles and discussions in social web sites, we can enumerate three major opinions from the C++ community :
- Using them, It’s the best way to handle exceptional circumstances.
- Using them but be very careful, they have some side effects.
- Never using them.
As C++ developer I’m very confused. Should I use Them or not?
There’s one common big issue invoked by all the C++ actors, it’s not trivial to write an exception safety code. We can classify C++ developers in four categories:
Category 1: Use C++ exceptions without care of exception safety code.
Category 2: Use C++ exceptions, and are aware of the safety code problematic.
Category 3: Not Use them but not know exactly the pros and cons of exceptions.
Category 4: Not Use them because they understand exactly the cons of using them.
The developers from categories 2 and 4, know exactly what they do. However, for the categories 1 and 3 they don’t master the exception mechanism, which could influence the quality of their code. Maybe it’s a false debate to discuss the uses of exceptions, what’s more important is : Did you know the pros and cons of using them? It’s up to you after to make a choice depending on your specific constraints. No one could blame you if you choose one of the two approaches.
