Exit Statement
An exit statement may appear inside a while-loop or a for-loop.
Note that phix uses break within a switch construct to resume control after the end switch, and it does not repurpose or overload that keyword to exit loops, unlike several other programming languages. Conversely, while desktop/Phix allows a (direct) exit within a switch statement, that becomes prohibited and generates a compilation/transpilation error under "with js", unless adequately nested, ditto (direct) break from within a loop, since JavaScript uses "break" for both loops and switch statements (and of course has no goto statement either, so we couldn’t even do that).
The exit statement causes immediate termination of the loop, with control passing to the first statement after the loop, for example
It is also quite common to see something like this:
If you happen to create a real infinite loop, when using p.exe keying control-c in the console will stop your program immediately.
However with pw.exe there may not be a console window, and your only option may be to terminate the process via Windows Task Manager.
To avoid that situation you may want to test (gui) programs using p.exe first, or create a console window at the start of the application, for instance by executing a puts(1,"") statement.
For legacy code only, the continue statement is similar, but causes the next iteration to begin immediately.
Control passes to the "end for" or "end while[+branch straightening]" statement. I will let you guess what this shows:
One trap for the unwary awaits: continue may trigger an infinite loop unless the required statement(s) in this kind of while loop are duplicated:
Note that phix uses break within a switch construct to resume control after the end switch, and it does not repurpose or overload that keyword to exit loops, unlike several other programming languages. Conversely, while desktop/Phix allows a (direct) exit within a switch statement, that becomes prohibited and generates a compilation/transpilation error under "with js", unless adequately nested, ditto (direct) break from within a loop, since JavaScript uses "break" for both loops and switch statements (and of course has no goto statement either, so we couldn’t even do that).
The exit statement causes immediate termination of the loop, with control passing to the first statement after the loop, for example
for i=1 to length(s) do
if s[i] = x then
location = i
exit
end if
end for
Which is basically what find() does, except that actually uses a return statement rather than a local variable.
It is also quite common to see something like this:
while true do
...
if some_condition then
exit
end if
...
end while
i.e. an "infinite" while-loop that actually terminates via an exit statement at some arbitrary point in the body of the loop.
If you happen to create a real infinite loop, when using p.exe keying control-c in the console will stop your program immediately.
However with pw.exe there may not be a console window, and your only option may be to terminate the process via Windows Task Manager.
To avoid that situation you may want to test (gui) programs using p.exe first, or create a console window at the start of the application, for instance by executing a puts(1,"") statement.
For legacy code only, the continue statement is similar, but causes the next iteration to begin immediately.
Control passes to the "end for" or "end while[+branch straightening]" statement. I will let you guess what this shows:
for i=1 to 5 do
if i=3 then
printf(1,"%d is three\n",i)
continue
end if
printf(1,"&d is not three\n",i)
end for
Douglas Crockford says "I have never seen a piece of code that was not improved by refactoring it to remove the continue statement", and
I must agree. In some programming languages a continue expressly restarts the same iteration without (re-)incrementing the control
variable or testing for termination. With that in mind, Edita/Edix now colour the continue keyword illegal, although technically it still
works, and pwa/p2js issues a gentle warning. Certainly I believe an else plus indent makes it far easier to visualise the control flow.
One trap for the unwary awaits: continue may trigger an infinite loop unless the required statement(s) in this kind of while loop are duplicated:
if alldone then exit end if --\ either
something += 1 --/ or both
end while
Obviously if you "continue" without somehow checking for completion/moving on, it will likely find the exact same reasons at the exact same place
and therefore re-perform the exact same "continue", forever. In contrast, a for loop/continue automatically performs an implicit control-var increment.