I Don't Use Exceptions in C++ Anymore

I Don't Use Exceptions in C++ Anymore

The use of exceptions is a polarizing topic in the C++ community. For my part, I was in the pro-exception camp ever since the release of C++11. My reasons were:

• Blessed by the standard library
• Cleaner code without repetitive error checking noise
• In widespread implementations there is no runtime cost when no exception occurs

These reasons outweighed a lot of the counterarguments I read over the years, many of which seemed to be founded in personal preference or predicated on the incorrect use of exceptions. Using exceptions in C++ desktop and server applications overall made sense to me.

As I expanded my usage of C++ into other domains, specifically embedded domains, I began to experience more compelling reasons not to use exceptions first-hand:

• Exceptions require runtime support, i.e. the compiler needs to generate code that assumes a specific host runtime environment to implement exceptions. This complicates things in unhosted or custom environments where that runtime support is not implemented or cannot be implemented without modifying the compiler.
• Exceptions require non-local memory allocation, e.g. malloc(), which is an additional runtime component that not all environments can provide.
• In real-time contexts throwing an exception can take a non-deterministic amount of time.
• Exceptions make interspersing C and C++ code error-prone. Calling C++ functions that can throw from C is an error yet that compiles without error.
• Exceptions require RTTI which may significantly increase output binary size.
• Exceptions can require unwind tables which may significantly increase output binary size.
• Exceptions remove some optimization opportunities, necessitating the use of noexcept.

Depending on your situation these drawbacks may range from mere annoyances to complete showstoppers.

Alternatives

At a high level, the standard alternative to using exceptions is to instead return a value from your function that signals whether it was successful or not. The two drawbacks to this approach are 1) you pay a cost for checking the value every time you call the function and 2) your code is littered with explicit comparisons.

For drawback 1), the cost is real but insignificant in nearly all cases. Usually this amounts to two extra instructions after the function call, e.g.:

    call    function_that_can_fail
    test    eax, eax
    jne     handle_error
    ;; continue processing as normal

Branches can be expensive but since errors are rare, you rarely pay for the cost of the branch. Usually you are only paying for the cost of the two extra instructions. Unless the function was in the middle of a hot loop, the additional cost is negligible. In most cases, calls to functions that can fail don’t happen in hot loops.

Drawback 2) can be a real issue. One workaround is to use a macro to generate the repetitive error-checking code, e.g.:

#define TRY(expr)    \
  do {               \
    auto _e = expr;  \
    if (_e) {        \
      return _e;     \
    }                \
  } while (0)

You can make this macro arbitrarily more versatile if you’d like. You can also use a library to handle these details for you, I’ve had success with the Outcome library.

Conclusion

When I reach for C++ I do so primarily because it enables writing code that can run in many different environments. Exceptions make it more difficult or impossible for me to use otherwise portable code in unhosted or custom environments. It’s a matter of pragmatism. For that reason I will default to avoiding exceptions altogether when I write C++ going forward.

Send any comments to @cejetvole.

Rian Hunter
2023-08-09