> Sorry, but it's a fact that exceptions introduce implicit control-flow branch points at each statement, potentially even multiple such.
THAT IS NOT A FACT AT ALL.
Those implicit control-flow branch points WILL HAVE TO BE DEALT WITH ANYWAY, they were already there. Only without exceptions you have to deal with them all at all positions in your code. Explicitly. You are writing code that is scaffolding code, not code that does what the program actually needs to do.
When you use exception, you write only the code that does what the program actually needs to do, with some sanity checks here and there. You follow the sanity rules, you are safe.
For instance, every time you open a file things can go wrong. Supposing you have a function call hierarchy main -> f -> g -> h, and h() wants to open a file, one of the following will happen:
1. you (generic "you", ok?) won't check open() results, will proceed as if the file was open, and undefined and terrible things will happen;
2. (try#2) you will check open() results, return an error code, g() does not check for the error code and proceeds, hilarity ensues;
3. (yes it finally works) g() checks h() error code, f() checks g() error code, main() checks f() error code, prints a suitable message.
4. (despair happenning) you have to call i() from g() and j() from f() and both have to open files. At this point, if you don't forget anything (you have to do every of these checks yourself, manually) you have a program that is at least 25% scaffolding.
With exceptions, one of those will:
1. open() throws, _main() aborts and prints "unexpected exception". The program already works.
2. (let's make this pretty) you put a catch() block on main(), print a pretty message cerr << "file " << name << " could not be open". The program still works.
3. (down the road) you have to add i() and j() and the program still works. No need to repeat step 2.
> Note that I was not advocating for error return codes.
No, but you are differentiating "implicit control-branch points" from "explicit" ones and it does give that impression. My point is that: implicit control-branch points are there anyway (you open a file, things can go wrong in the process), and dealing with them implicitly is better then explicitly.
Yes, dealing implicitly with exceptions means that sometimes you have to be exceptionally (ha!) safer (constructors/destuctors). But it just helps you to clarify your code and tell better when things can go wrong.