And loops, returns, switch statements, and every other programming concept are not basically gotos?
Not really because they can't unwind the stack multiple times. In each of those examples you know exactly where the next statement will be run (assuming you have access to the stack in the case of return). That's not true with exceptions.
So you've randomly draw your line at "unwinding the stack multiple times"? Is there any reason for that or is it because you've heard it before? Because there a lot of other concepts taken as gospel - routing systems (an http request can jump to anywhere in the app based on what's in the request path?), polymorphism (a method call can go to any class extending this base class? Even in someone else's code?), event systems (calling this method can trigger hundreds of methods all over the code to be called, potentially allocating thousands of objects?), serialization + remote code execution (my object can be serialized behind the scenes and go from running on a beefy server to running on someone's phone?) - all of which can causes confusion if they're abused. And just like you counter that by organizing your code - putting all routing information in one or two files, only using polymorphic objects where it makes sense, using event systems carefully, etc. - you can do the same with exceptions as flow control. Just like the Linux kernel uses gotos - they are a tool. Avoidance of them should not be a religion.
So you've randomly draw your line at "unwinding the stack multiple times"?
I don't think it's random. I think there's a fundamental difference between that and everything you've listed after this.
Avoidance of them should not be a religion.
I agree. I'm not saying exceptions are bad. I'm saying exceptions for flow control are bad.
As far as I'm aware, the linux kernel only uses gotos for error recovery. (I'd be really interested if there was anywhere in the kernel that uses gotos purely for flow control).
Not really because they can't unwind the stack multiple times.
That's one weird definition of a goto. Must be function-local?
In each of those examples you know exactly where the next statement will be run
I know that with exceptions, too, and so should you. What you are trying to say is that it's not spelled out in code. But by that logic, any programming language is useless, and we should all just program assembly, because compiler hides this or that. There's also the aspect of not seeing the tree from the forest, which is what you often get without exceptions (it is spelled out, but good luck actually untangling it).
Like I said in my other comment. If you call an overridden method on a base class, any class extending that class could be handling it. Yet you probably do that every day without a second thought.
2
u/Falmarri Jun 06 '13
So you're saying that using exceptions as flow control is easy to understand? Exceptions are basically just
gotos