On 14/06/2017 21:52, Richard Hodges wrote:
Exception return paths are not infinite. There are a finite number of places in code that an exception can be thrown.
Correct. There are infinite possible types that can be thrown.
The exception path is one path, the non-exception path is another. That’s two in total. Exactly equivalent to an outcome<>.
Right.
It is a fallacy to say that there are an indeterminate number of paths.
I stand corrected. Let me rephrase my assertion: with errors you have a limited range of values in a single type that you must handle. With exceptions you have an indeterminate number of types, each of them with a limited number of states/values. If you want to "handle" all of them, you need an undetermined number of catch statements because the type can be absolutely unknown to the handler. The programmer that must handle the exception can't be prepared for that. Instead, the programmer can be prepared to handle a limited number of exceptions that a function might throw, but that implies translating lower layer exception types to a finite number of exception types, which is very similar to handling and translating error codes. Exceptions shine when the programmer refuses to handle errors.
If developers do not understand RAII, then an afternoon of training can solve that.
RAII is the foundation of correct c++. It is the fundamental guarantee of deterministic object state. A program without RAII is not worthy of consideration. The author may as well have used C.
You can't correctly write exception safe code only with simple RAII. There are chained operations that must be undone on the presence of an error. If the exceptional path is not explicit, it is very easy to incorrectly handle it or just to ignore that path. Just like strong types are safer, explicit paths are safer. Exceptions imply weakly defined control paths. And that's a real problem for safety. Exceptions are great when you don't want to handle the exception, so the compiler automatically propagates control to the upper layers.
Perhaps there is an argument that says that RAII adds overhead to a program’s footprint. If things are that tight, fair enough.
Otherwise there is no excuse to avoid exceptions. I’ve never seen a convincing argument.
The fact that people are taking time to re-implement exception functionality in outcome<> et al demonstrate the necessity and correctness of exceptions.
If people reimplement exceptions, it's because many are not happy with them, even decades after exceptions were added to C++. Nobody rewrites "while" with "goto"s.
I have yet to see an answer to my initial question - an example of code in which compiling without exceptions enabled and checking return types instead, will add any performance benefit to the non-exceptional case at all. with table-based implementations, I don't think there is any.
Ion