{"id":311,"date":"2018-02-04T17:52:37","date_gmt":"2018-02-04T17:52:37","guid":{"rendered":"http:\/\/cppdepend.com\/blog\/?p=311"},"modified":"2023-05-31T16:39:12","modified_gmt":"2023-05-31T16:39:12","slug":"to-use-or-not-to-use-cpp-exceptions-debate","status":"publish","type":"post","link":"https:\/\/cppdepend.com\/blog\/to-use-or-not-to-use-cpp-exceptions-debate\/","title":{"rendered":"To Use or Not To Use: C++ Exceptions Debate"},"content":{"rendered":"

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.<\/p>\n

Let\u2019s discover the opinion of some C++ actors, and what they think about the use of the exception mechanism.<\/p>\n

I- C++ experts<\/strong><\/p>\n

Herb Sutter From its article:<\/em><\/strong><\/p>\n

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\u2019t control all possible calling code and can\u2019t 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.<\/p>\n

Bjarne stroustrup from its FAQ page:<\/em><\/strong><\/p>\n

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\u2019s wrong with \u201cgood old errnoand if-statements\u201d? 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 \u201cspaghetti code\u201d or a \u201crat\u2019s nest of tests\u201d).<\/p>\n

Scott Meyers from its \u201cEffective C++\u201d book:<\/em><\/strong><\/p>\n

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.<\/p>\n

Joel Spolsky from its article:<\/em><\/strong><\/p>\n

People have asked why I don\u2019t like programming with exceptions. In both Java and C++, my policy is:<\/p>\n

1 \u2013 Never throw an exception of my own
\n2 \u2013 Always catch any possible exception that might be thrown by a library I\u2019m using on the same line as it is thrown and deal with it immediately.<\/p>\n

Andrey Andrescu from its article<\/em><\/strong><\/p>\n

Writing Exception-Safe Code Is Hard<\/p>\n

And later in the same article, he explains how using exceptions could be simplified using the scope guard idiom:<\/p>\n

ScopeGuard is a generalization of a typical implementation of the \u201cinitialization is resource acquisition\u201d C++ idiom. The difference is that ScopeGuard focuses only on the cleanup part \u2014 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.)<\/p>\n

Jhon Kalb from its website<\/em><\/strong><\/p>\n

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\u2019ll start with \u201cWhat is the problem we are trying to solve?\u201d 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.<\/p>\n

II- Real projects:<\/strong><\/p>\n

From the Boost style guide:<\/em><\/strong><\/p>\n

When should I use exceptions?<\/p>\n

The simple answer is: \u201cwhenever the semantic and performance characteristics of exceptions are appropriate.\u201d<\/p>\n

From the google style guide<\/em><\/strong><\/p>\n

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.<\/p>\n

Clang<\/em><\/strong><\/p>\n

The Clang team decide to not use the C++ exceptions, here\u2019s a citation from their coding standard:<\/p>\n

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 \u201cyou only pay for what you use\u201d, 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.<\/p>\n

In the other side LibreOffice uses the C++ exception mechanism.<\/p>\n

When exploring many known C++ open source projects, there\u2019s no preferable choice. The two approaches are widely used.<\/p>\n

III- C++ community<\/strong><\/p>\n

If we search in forums, articles and discussions in social web sites, we can enumerate three major opinions from the C++ community :<\/p>\n