5 ms·
Exceptions are, in essence, sophisticated GOTO statements. Programming with exceptions, therefore, leads to more difficult to read, and understand code. Most la
by weatherlight 5y ago
Exceptions are, in essence, sophisticated GOTO statements.
Programming with exceptions, therefore, leads to more difficult to read, and understand code.
Most languages have existing control structures designed to solve problems without the use of exceptions.
Arguments for efficiency tend to be moot for modern compilers, which tend to optimize with the assumption that exceptions are not used for control flow. This just feels like it's going to get abused.
- da39a3ee 5y ago> This just feels like it's going to get abused. It's not clear what you mean here: the proposal is not changing any user-facing functionality, just making something faster that already existed. As far as I know Python has always had exceptions.
- hakfoo 5y agoI thought that exceptions were intended for the one situation where people more or less agreed goto could be a net positive for legibility: "I'm twelve nested loops in and realize that I can't proceed, how do I bail out?" The alternative I've seen tends to be something like "set $faulted when you realize something is unrecoverable, then make sure the entire rest of the function checks for it and makes sure not to do anything else if we've already identified a fault."
- throwaway81523 5y agoThere is a trend now to replace goto-like exceptions with compiler-supplied error checks like you describe: http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0709r0.pdf http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0709r0.... This is likely inspired by the Error monad in Haskell, and the doc might say so explicitly (I don't remember).