I would say that if you can't jump out of a FOR-NEXT and then jump back into it, or jump into it while bypassing the FOR, you have a 'design flaw' in the sense that you aren't allowing the things which you permit to be done.
If you're going to permit it you ought to support the doing of it.
This below may be a horrible, horrible mess, but there's no reason to not allow it if you've embraced GOTO and spaghetti coding, and, if you are going to allow it, IMO you owe the programmer an obligation of doing what they want done.
Code: Select all
Start: var = 10 Goto JumpIn MyLoop: For var = 0 To 20 Goto Adjust JumpIn: Print var Next Goto Start Adjust: var = var + 2 Goto JumpIn
If you give an error on the "Goto JumpIn" commands at compile time I would accept that as fair enough. But if you don't then you are failing to deliver what a programmer would expect to be delivered. You are creating an ambiguous ' you can do that, and I'm not going to complain if you do, but I'm not going to allow it to work when you run it'.
The programmer shouldn't have to guess what implementation decisions you took which prevent things working.
Bottom line is, IMO, if you are going to allow GOTO you shouldn't introduce stack controlled structures, you need to find a way to do it without a stack. If you are going to use stack structures then things which patently or obviously break that stack shouldn't be allowed to get through compilation.
Now I do agree it's a viewpoint issue. Some may say it's okay to let that through and have it crash as much as it is to let 'var=var/0' through and let that crash; it's the programmer's fault for getting it wrong. But I see compilers as there to save programmers from themselves, not leave them to be surprised when code passes syntax checking and then fails at run-time when the compiler knows it would, or should know that.