Using exceptions in C++ desktop and server applications overall made sense to me.
As I expanded my usage of C++ into other domains, specifically embedded domains, I began to experience more compelling reasons not to use exceptions first-hand...
It's a shame that sum type support is still so lacking in C++. Proper Result types (ala Haskell or Rust) are generally much nicer to deal with, especially in embedded contexts.
As is, there's only std::expected (which can and will blow up in your face if you forget to check has_value) and std::variant, which I have heard nothing but complaints about.
It’s a shame that sum type support is still so lacking in C++. Proper Result types (ala Haskell or Rust) are generally much nicer to deal with, especially in embedded contexts.
I don't think this is a lack of support in C++. There are already a few C++ libraries that implement Either and Result monads. It would be nice if those were supported in the C++ stand library, but that does not stop anyone from adopting them.
I would consider language support essential for "good" sum types. AFAIK, stuff like exhaustive pattern matching can't be accomplished by a library. Perhaps you could do some cursed stuff with compiler plugins, however.
(There was a library that implemented non-exhaustive pattern matching that eventually morphed into an ISO C++ proposal... so we won't see it until 2030 at the earliest /hj)
Another alternative to C++ exceptions (instead of return code) is to use global (or thread local) variable. This is exactly what errno that C and POSIX are using or GetLastError what Windows is using. Of course, this has its own pros and cons.