[jesse__]

My issue with exceptions is also practical. If they didn't introduce significant stability issues, I'd have no problem. As it stands, it's impossible to write robust software that makes use of C++ exceptions.

> the compiler will require you to deal with it somehow in g

I agree, this is the sensible solution.

[yunnpp]

What stability issues?

[rauli_]

Unchecked exceptions will eventually lead into programs crashing because some developer forgot to catch specific type of exception somewhere.

[drysine]

And developers never forget to check error codes.

[dan00]

Looking at code, it‘s easier to spot the missing check for an error code, than a not catched exceptions.

Also error codes are part of the signature of a function, which exceptions aren‘t.

[drysine]

If you need to wrap each call in try/catch, it's better to use return codes in some form or rethink the approach.

[listeria]

may I introduce you to the nodiscard attribute[1]?

  enum (class)? [[nodiscard]] Error {
    Ok,
    NoMem,
    ...
  };

[1]: https://en.cppreference.com/w/cpp/language/attributes/nodisc...

[drysine]

   C attribute: nodiscard (since C23)

[1] https://en.cppreference.com/w/c/language/attributes/nodiscar...

[senderista]

FWIW I’ve been using warn_unused_result in both gcc and clang since about 2020.

[ahtihn]

That seems like a better outcome than continuing when an error happened while thinking everything succeeded?

[yunnpp]

Yes, but that's not a dichotomy. Languages like Java have function declare what exceptions they throw, and the caller must either catch it or also declare that it throws it. Gets cumbersome quickly, but I believe it's for the best to encode exceptions at the type system.