The C++ standard for the F-35 Fighter Jet [video]

I guess a bigger conversation could be had in regards to:

what leads to better code in terms of understandability & preventing errors

Exceptions (what almost every language does) or Error codes (like Golang)

are there folks here that choose to use error codes and forgo Exceptions completely ?

There isn't much of a conversation to be had here. For low-level systems code, exceptions introduce a bunch of issues and ugly edge cases. Error codes are cleaner, faster, and easier to reason about in this context. Pretty much all systems languages use error codes.

In C++, which supports both, exceptions are commonly disabled at compile-time for systems code. This is pretty idiomatic, I've never worked on a C++ code base that used exceptions. On the other hand, high-level non-systems C++ code may use exceptions.

thanks for the explanation.

What you wrote is historically correct, but new analisys shows exceptions are faster that error codes if you actually check the error codes. Of course checking error codes is tedious and so often you don't. Also is micro benchmarks error codes are faster and only when you do more complex benchmarks do exceptions show up as faster.

The performance benefits of exceptions are not borne out in practice in my experience relative to other error handling mechanisms. It doesn't replicate. But that is not the main reason to avoid them.

Exceptions have very brittle interaction with some types of low-level systems code because unwinding the stack can't be guaranteed to be safe. Trying to make this code robustly exception-safe requires a lot of extra code and has runtime overhead.

Using exceptions in these kinds of software contexts is strictly worse from a safety and maintainability standpoint.

The cost depends greatly on details. If you are returning an error and handling it in the next function down, then error codes are better. However if you have to unwind several levels of stack then exceptions are faster (assuming a modern optimized implementation - in many cases the compiler is locked into an ABI that cannot be optimized...)

> unwinding the stack can't be guaranteed to be safe.

While this is true, it is a bad argument. If unwinding the stack isn't safe then you likely have lots of issues because you forgot about some code real code path that can also have the effect of skipping the area where you do the needed cleanup. In effect cleaning up to make unwinding safe will also have the effect of making your code better in the other cases too.

This argument also fails in a different way: if your stack is safe to unwind that means it is easy to test all the code paths that unwind. Testing error paths is often hard and so skipped - which means exception safe code is more likely to be correct because the code paths are run all the time.