That exact same problem exists in C in the exact same way. It's somewhat less of an issue just because C is essentially frozen in time, but it has the same inhe

That exact same problem exists in C in the exact same way. It's somewhat less of an issue just because C is essentially frozen in time, but it has the same inherent problems & design issues. But if you statically link your C++ runtime & only expose C interfaces then you're fine. You can be "just like C" only at the ABI boundary, that's well supported and works great. It's a quite common setup even. Like for your particular example I don't think the solution to "in some situations I can't throw exceptions across an ABI boundary" is "switch to a language where exceptions don't exist at all and error handling is 'good luck'". It'd be nice if there was a way to flag an exported symbol as being ABI sensitive & letting the compiler patch up differences, that'd be a nice feature. Nuking it entirely seems like the opposite of a solution though? But you're still free to do that in C++ if you want. noexcept all your exported symbols & use error returns, just like C. Or even just compile with exceptions disabled entirely.