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:
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:
malloc()
, which is an additional runtime component
that not all environments can provide.noexcept
.Depending on your situation these drawbacks may range from mere annoyances to complete showstoppers.
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.
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