[stdplaceholder]

It results in slower generated code and much larger binaries, neither of which would be acceptable to Google (some of their binaries are already on the brink of being unbuildable, so a bunch of junk to enable exceptions is not possible.)

[hendzen]

the slower generated code is an academic concern. Show me a realistic/non-contrived benchmark where not keeping the stack unwindable actually helps give a useful performance increase. Error codes force people to litter the code with branches and put error handling code in the hot path of the instruction stream.

[cma]

Using 'likely/unlikely' compiler directives, the instructions in the unlikely error branch can be hoisted out to another area and not significantly affect instruction cache. It still is a branch though.

[jcelerier]

and exception-based code can have much less branches since you don't need to check every function call for error but instead let the exception propagate from where they can be thrown. e.g. in a hypothetic case where you load a settings file five layers deep, in an error-code-based solution you have potentially 5 branches while in an exception-based solution you only have one

[tpolzer]

At the cost of predictable performance though. With current implementations, the exceptional path will be several magnitudes (!) slower for cheap functions.

[ridiculous_fish]

Exceptions impose indirect costs other than just code size. For example, when std::vector reallocates, it copies instead of moves its elements, in case the move constructor throws and leaves the vector in an inconsistent state.

[je42]

Also... there is a proposal to fix the overhead of the code that current compilers generate for exception based code.

P0709 R0 – Zero-overhead deterministic exceptions

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p070...