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.

▲

jandrewrogers 2 days ago | parent [-]

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.

	▲	bluGill a day ago \| parent [-]
		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.