Infinite Loops and Reliable Exit Conditions
Let a retry end even when the answer never arrives
A school device checks for a registration response. It should retry a limited number of times and then report failure rather than freezing forever when no response is available.
An infinite loop continues without reaching an exit during the execution being considered. A useful loop needs a stop condition and progress toward it, or an intentional external cancellation mechanism.
Trace progress
Identify the state changed by every iteration.
Bound retries
Use an attempt limit even when success never occurs.
Find trapped paths
Recognize updates skipped by continue and conditions that never become false.
A failed retry still makes progress
Start
No attempts have been made.
attempts = 0Repeat with progress
Every unsuccessful attempt increases the count.
1 → 2 → 3Exit
The maximum has been reached.
3 < 3 → false
Ask what will make the next condition different
A loop condition can start true and stay true if the body never changes what it tests. For example, testing attempts < 3 while never updating attempts prevents that condition from becoming false.
A finite attempt bound provides an exit even without success. This synchronous example explains control flow only; a real network retry also needs timeouts, cancellation and an appropriate delay policy.
Before starting, review break, continue and skipped updates. These examples use JavaScript; other languages can use different syntax and rules.
Retry at most three times
The body increments attempts before printing. Starting at zero, it prints attempts 1, 2 and 3. The next condition is false, and execution reaches Finished.
We do not run an intentionally unbounded faulty loop in the lesson. Its problem is explained by the unchanged state rather than by freezing the browser.
JavaScript · local teaching example
let attempts = 0;
const maximumAttempts = 3;
while (attempts < maximumAttempts) {
attempts += 1;
console.log('Attempt ' + attempts);
}
console.log('Finished');Expected output
Attempt 1
Attempt 2
Attempt 3
FinishedSuccess can stop a bounded loop earlier
This simulation treats the second attempt as successful. Break exits the loop at two, while the maximum would still stop it if no attempt succeeded.
The condition is simulated, not a network availability guarantee. A real response must be checked and validated.
JavaScript · local teaching example
let attempts = 0;
while (attempts < 3) {
attempts += 1;
if (attempts === 2) {
console.log('Registered');
break;
}
}
console.log(attempts);Expected output
Registered
2Apply the rule to a small change
Allow zero attempts and predict which body instructions run. Then explain how increasing the bound to two changes the trace.
Worked answer
With a zero maximum, the initial condition is false, so no attempt runs and only Finished is printed. With a maximum of two, attempts 1 and 2 run before finishing.
JavaScript · local teaching example
let attempts = 0;
const maximumAttempts = 0;
while (attempts < maximumAttempts) {
attempts += 1;
console.log('Attempt ' + attempts);
}
console.log('Finished');Expected output
FinishedRecognize mistakes and limits
Every path that repeats must preserve progress. A continue before the attempts update can bypass it. Updating the wrong variable is just as dangerous as omitting the update. Trace the specific executed path rather than spotting an increment somewhere in the body.
Some services intentionally loop while running, but they still need responsive waiting and a shutdown route. A busy synchronous loop blocks JavaScript’s thread; a timer cannot interrupt that blocked work to rescue it. External work also needs a timeout, since a finite number of attempts does not bound one attempt that never finishes.
For the language or tool rules used here, see JavaScript iteration rules.
Check the core idea
JavaScript · code for this question
let attempts = 0;
const maximumAttempts = 3;
while (attempts < maximumAttempts) {
attempts += 1;
console.log('Attempt ' + attempts);
}
console.log('Finished');Apply the idea to a new situation
Prove progress on every repeating path
A safe exit needs a condition that can change, an update that actually runs, and bounds for external work. Use zero-iteration, success and all-failure cases to test the control flow.
Connect this idea with condition-controlled loops and timeouts for external operations.
Reaching the recap and completing the quizzes are separate milestones.