Tony Wesley wrote:
The goto doesn't figure into that. Just above it in the thread is another snippet of my code that doesn't use a goto. Same issue. What happens to the code after the while loop when an exception is thrown? It doesn't get executed. Once could argue that the problem is with exception. As I pointed out elsewhere, Joel Spolsky argues that exceptions [...] create an abrupt jump from one point of code to another. In fact they are significantly worse than goto's: (emphasis added) I don't quite agree with Joel. But there was a time, when I was debugging an app that another programmer had written, that I understood that completely. It was spaghetti exception handling. I never knew where I had come from. I'm not saying you shouldn't use exceptions. But they can be abused as badly as gotos.
I'm talking about the case where coders like to put a block of cleanup code at the bottom of a method and "goto" it when something goes wrong or fall into it in a non-error situation. If you are depending on blocks of cleanup code, an exception will bypass it completely. This worked back in C, but not in OO design. That's why I use objects that clean themselves up when destroyed -- automatically. I am far too lazy to try to figure out every possible error situation, catch exceptions from anything that might throw them, and ensure that there is an appropriate goto. I disagree completely with Joel Spolsky. He suggests using return codes instead of exceptions. Return codes and exceptions are completely different things. Exceptions are not meant to be return codes. They are "exceptional" situations where usually the app cannot continue. And exceptions have the major advantage of unwinding the stack, which he fails to mention. They are not "an abrupt jump from one point of code to another." It seems like OO programming has really failed to catch on with a lot of developers.
modified on Sunday, December 16, 2007 12:10:46 AM
