C++ exception model is complex and the implementations are intricate. I do not think you one can easily dismiss the possibility of runtime overhead just because

C++ exception model is complex and the implementations are intricate. I do not think you one can easily dismiss the possibility of runtime overhead just because it seems like no extra work is done. It's much more subtle that that. The implementation potentially affects inclining opportunities, compiler complexity, code caching etc. On modern CPUs, probably the most efficient exception model is one that simply uses error codes. Especially when paired with an optimised calling convention like what Swift does. Checking for an error flag is essentially free on a superscalar CPU anyway and all this stuff is transparent to the compiler, simplifying the translation process and enabling more optimisation opportunities. P.S. I ran a bunch of tests with C++ a while ago and a Result-like type error handling (implemented sanely) was always as fast as C++ exceptions for the good path and faster for the bad path — unless you are going a hundred or so nested functions deep (but then you have a massive code smell problem anyway). With an optimised calling convention it is likely to be even better.