Exceptions for Error Handling

This seems like a mistake. From my perspective it looks like the C++ community as a whole is moving away from exceptions. I see a few justifications for this:

1. Exceptions require runtime, i.e. the compiler needs to generate code that assumes a specific host runtime environment to implement exceptions. This limits the usability of C++ in embedded or unhosted contexts which are important domains of C++.
2. (related) Exceptions require malloc()/heap/non-local memory allocation, which is an additional runtime component that not all environments need to provide.
3. Exceptions make interspersing C and C++ code dangerous and error-prone. Calling C++ functions that can throw from C is an error yet can easily be done.
4. Exceptions require RTTI which results in binary bloat.
5. Exceptions can require unwind tables which results in binary bloat.
6. Exceptions remove some optimization opportunities, which was one of the reasons for the emergence of “noexcept.”

There are likely more practical issues with exceptions. I don’t think any of these issues can be ignored and I think it’s a matter of time before the standards committee catches up. In my projects I use the outcome library as an error container library but the future std::expected seems practically equivalent.

Yes, there are some practical issues with return-value based error libraries as well. Off the type of my head:

1. Limits RVO in leaf calls that return the same value but use different error types, or same error types but different values.
2. Syntactically cluttered, requires manual checking of return value on every function call. Macros can help but using macros everywhere can feel dirty.

The point 1) can be addressed to a large extent by using TLS to store the error type, this is what LEAF does. 2) can be addressed with language support, similar to how Rust introduced the ? sugar.