nope, definitely not thinking of asserts, they are nothing to do with this situation.
program logic encoded in an exception handler is undeniably less easy to read than explicitly coded error cases.
Also, the non-locality of the decision making means the further away from the error-site you are, the more context you have to keep in your head.
This similar to what deep inheritance hierarchies suffer from, non-local logic. you end up jumping all around your source tree trying to figure out the full context that an error has occurred in.
"program logic encoded in an exception handler is undeniably less easy to read than explicitly coded error cases"
For which category of exceptions? For interaction with non-deterministic systems where you can make a localized decision - and this is fairly rare - I'd agree with you. For all the other categories, I think you're wrong. If you never used exceptions in the other ways, this will of course colour your thinking.
That's a very strong statement. You really believe there can't possibly exist any instance where program logic in an exception handler ends up being easier to read? That assumes you know enough about every possible permutation of logic flow to know that exceptions could not benefit it.
Sure. The real point I'm getting at is that overly strong statements lead to arguments, where people take your statement at face value. Hyperbole is rarely useful in a serious discussion. It just means people have to work to determine your real stance because it may not match exactly what you said.
You could have said "I've never seen a case where exception handling resulted in more clear and easier to read code, and I doubt I'll ever encounter such a situation" and I think that would convey your opinion clearer (assuming I understand it correctly).
> No rules are universal.
We're talking about CS and programming here, where there are plenty of cases where things have been formally proven. Some rules are universal. No reason to use absolutist statements where they don't apple.
program logic encoded in an exception handler is undeniably less easy to read than explicitly coded error cases.
Also, the non-locality of the decision making means the further away from the error-site you are, the more context you have to keep in your head.
This similar to what deep inheritance hierarchies suffer from, non-local logic. you end up jumping all around your source tree trying to figure out the full context that an error has occurred in.