IF/ELSE, FOR, WHILE, TRY/EXCEPT, BREAK, CONTINUE, and Control Flow: Diagnostics, Failure Modes, and Production Practices

1. Diagnostic sequence

1. Preserve the failing output.xml, log.html, report.html, exact command, and any local trace.
2. Confirm Robot/Python version and executed suite path.
3. Validate parse structure: every native block has correct markers and END.
4. Inspect condition inputs and whether ${var} replacement or $var object access was intended.
5. Inspect the first failing keyword and exact message before looking at recovery.
6. Check whether EXCEPT matching, BREAK/CONTINUE, or a loop limit altered the path.
7. Inspect external state only if the executed keywords actually touched it.
8. Apply the least destructive correction and rerun the smallest slice.

2. Failure mode: an effectively unbounded WHILE

This example disables the framework limit and can run forever. It is intentionally unsafe and must not be executed:

*** Test Cases ***
DO NOT RUN — Infinite Loop
    WHILE    True    limit=NONE
        Log    no convergence condition
    END

The repair is not “add a bigger sleep.” Define the expected convergence signal and a small count/time budget. If each iteration calls an external system, record attempt number and observed state so the final failure explains what happened.

3. Failure mode: broad EXCEPT hides an assertion

*** Test Cases ***
Broken Recovery
    TRY
        Should Be Equal    actual    expected
    EXCEPT    AS    ${error}
        Log    ignored=${error}
    END
    Log    Test now continues and may pass — misleading.

The assertion is the test’s evidence; catching it broadly defeats the test. Repair by removing recovery, or catch only a known operational failure with a stable contract:

TRY
    Validate Synthetic State    transient
EXCEPT    transient:*    type=GLOB    AS    ${error}
    Log    Expected transient condition: ${error}
END

4. Failure mode: string truthiness assumptions

Python expression truthiness treats any non-empty string as true. The text "False" is therefore truthy. If a command-line/environment source yields text, compare or convert deliberately instead of writing IF $enabled and assuming semantic boolean behavior.

VAR    ${enabled_text}    False
IF    $enabled_text == "True"
    Log    enabled
ELSE
    Log    disabled
END

5. Failure mode: BREAK inside a called keyword

*** Test Cases ***
Broken Loop Control
    FOR    ${item}    IN    one    two
        Decide To Break    ${item}
    END

*** Keywords ***
Decide To Break
    [Arguments]    ${item}
    IF    $item == "two"
        BREAK
    END

This is invalid because BREAK is not in the active loop body. Return a decision instead:

FOR    ${item}    IN    one    two
    ${stop}=    Should Stop    ${item}
    IF    ${stop}    BREAK
END

6. Failure mode: constructing executable expressions from external text

Do not build strings such as "${external} == 'ok'" and feed them to Evaluate or a condition. If ${external} is not trusted, it can alter the expression. Keep the expression static and pass external content through the evaluator namespace using $external.

7. Failure mode: retry loops without first-failure evidence

A loop that catches every failure, increments an attempt, and retries can erase the most informative first error. If polling is legitimate, log each observed state and catch only the transient class that authorizes another attempt. Permanent validation failures must leave the loop immediately.

Poll With Narrow Recovery
    [Arguments]    ${max}=4
    ${stop}=    Evaluate    int($max) + 1
    FOR    ${attempt}    IN RANGE    1    ${stop}
        TRY
            ${state}=    Read Synthetic State    ${attempt}
            Should Not Be Equal    ${state}    invalid
        EXCEPT    transient:*    type=GLOB    AS    ${error}
            Log    attempt=${attempt}; transient=${error}
            CONTINUE
        END
        RETURN    ${state}
    END
    Fail    No successful state in ${max} attempts

8. Failure mode: wrapper-heavy control hides structure

New suites should not build nested Run Keyword If plus Exit For Loop If constructs when native IF/BREAK expresses the same path directly. The wrapper style is still supported for compatibility and dynamic dispatch, but it increases argument-level nesting and makes the log harder to read.

9. Performance diagnosis

10. Intentionally broken diagnostic exercise

Run this only against synthetic local values. It contains two defects: the broad handler hides a permanent failure and the WHILE budget is disconnected from the domain requirement.

*** Test Cases ***
Broken Diagnostic Case
    VAR    ${attempt}    ${0}
    WHILE    True    limit=1000
        ${attempt}=    Evaluate    $attempt + 1
        TRY
            Fail    permanent: invalid configuration
        EXCEPT    AS    ${error}
            Log    retrying after ${error}
        END
        IF    $attempt >= 3    BREAK
    END

Repair by removing the broad recovery for permanent:* and replacing the oversized loop with a small explicit attempt contract. The repaired test should FAIL immediately with the permanent message.

11. Troubleshooting shortcuts to reject

• limit=NONE in unattended automation.
• Catch-all EXCEPT around assertions.
• Turning every failure into a Boolean and continuing.
• Splicing external strings into expressions.
• Retrying without recording the first error and observed state.
• Adding sleeps instead of defining the condition or deadline.
• Deleting output artifacts before diagnosing the original path.

12. Knowledge check

13. Summary and next step

Control-flow diagnosis starts with the first failing path, not with retries. Bound loops, use object-safe expressions, keep BREAK/CONTINUE in the active loop body, and recover only the failure class your contract actually understands. Lesson 5 combines these rules in a checkpoint state machine with two injected failure classes and a refactoring exercise.

Further reading

• Robot Framework 7.4.2 User Guide — control structures — FOR, WHILE, BREAK/CONTINUE, IF/ELSE, TRY/EXCEPT, and readability guidance.
• Robot Framework 7.4.2 User Guide — WHILE loops — expression evaluation, limits, on_limit, and output-size considerations.
• Robot Framework 7.4.2 User Guide — TRY/EXCEPT — exact/pattern matching, AS, ELSE, FINALLY, and uncatchable failures.
• Robot Framework 7.4.2 User Guide — evaluating expressions — ${var} replacement versus $var access and evaluation namespace behavior.
• Robot Framework 7.4.2 BuiltIn — legacy-compatible conditional/loop-control helpers and native-syntax recommendations.
• Robot Framework project site — current stable release stream.