5 ms·

It is true that C++ exceptions are not checked and are rarely part of the interface signature but C++ exceptions are not a tool for general error handling in th

It is true that C++ exceptions are not checked and are rarely part of the interface signature but C++ exceptions are not a tool for general error handling in the context you're comparing them against Java, Zig and Rust. Java uses exceptions for control flow while C++ doesn't. Zig and Rust don't have exceptions at all. What Zig and Rust have as error handling mechanisms C++ has them too. C++ exceptions are of a literal meaning - exceptional cases which you don't expect to happen and you usually don't know how to recover from. In this case propagating the exception up to the thread entry point and doing whatever in that case (logging, terminating, restarting, etc.) is vastly better than language forcing me to check for each possible exception all the way through the whole function callstack - it's useless.

AnimalMuppet 3y ago
In what way are Java exceptions part of flow control and C++ exceptions aren't?
- menaerus 3y ago
  Although theoretically possible there will be rarely any C++ codebase that will use exceptions for control flow.
- vips7L 3y ago
  Honestly who cares if they are? Error handling is control flow.
masklinn 3y ago
> It is true that C++ exceptions are not checked and are rarely part of the interface signature but C++ exceptions are not a tool for general error handling They’re literally the only way to report ctor errors. > What Zig and Rust have as error handling mechanisms C++ has them too. Only in the most reductive way that all langages are turing complete, in which case Java has them as well.
- menaerus 3y ago
  > They’re literally the only way to report ctor errors. The point being? Please go find me a codebase which wraps object instantiation in try-catch clause if that's what you are trying to say. I haven't seen any. Anyway, for that reason constructors are always written so that they cannot fail in hideous ways, and if there is no other way around it there is always 2-phase initialization (personally I think it's an anti-pattern). > Only in the most reductive way that all langages are turing complete, in which case Java has them as well. Nonsense. Zig AFAIU abstracts error types as some sort of integer enums while OTOH Rust has Result<T, E>. C++ has both of those mechanisms baked either into the language (enum) or standard library (std::expected, std::optional).

AnimalMuppet 3y ago

In what way are Java exceptions part of flow control and C++ exceptions aren't?

menaerus 3y ago
Although theoretically possible there will be rarely any C++ codebase that will use exceptions for control flow.
vips7L 3y ago
Honestly who cares if they are? Error handling is control flow.

masklinn 3y ago

> It is true that C++ exceptions are not checked and are rarely part of the interface signature but C++ exceptions are not a tool for general error handling They’re literally the only way to report ctor errors. > What Zig and Rust have as error handling mechanisms C++ has them too. Only in the most reductive way that all langages are turing complete, in which case Java has them as well.

menaerus 3y ago
> They’re literally the only way to report ctor errors. The point being? Please go find me a codebase which wraps object instantiation in try-catch clause if that's what you are trying to say. I haven't seen any. Anyway, for that reason constructors are always written so that they cannot fail in hideous ways, and if there is no other way around it there is always 2-phase initialization (personally I think it's an anti-pattern). > Only in the most reductive way that all langages are turing complete, in which case Java has them as well. Nonsense. Zig AFAIU abstracts error types as some sort of integer enums while OTOH Rust has Result<T, E>. C++ has both of those mechanisms baked either into the language (enum) or standard library (std::expected, std::optional).