Java Flow Control: if/else, switch and Loops (1Z0-831)

An if statement runs its body only when its condition is true, and an optional else runs when it is false. Each branch is a single statement; braces turn several statements into one block. When braces are omitted, an else always belongs to the nearest preceding if that has no else yet — indentation means nothing to the compiler.

public class Main {
    static String pick(int h) {
        String r = "";
        if (h >= 6)
            if (h < 12)
                r += "morning";
        else
            r += "late";
        return r + ";";
    }

    public static void main(String[] args) {
        System.out.println(pick(9) + pick(15) + pick(3));
    }
}

This prints morning;late;;. The else is indented as if it belonged to if (h >= 6), but it binds to the inner if (h < 12). So for 15 the outer test is true, the inner test is false and late is added; for 3 the outer test is false and, because the outer if has no else of its own, nothing is added at all. Braces around the inner if are the only way to attach the else to the outer one. The same rule explains a statement that is indented as if it were part of an else or else if branch: without braces, only the first statement after else belongs to it, and the next one runs whatever the conditions were.

An else if chain is simply an else whose single statement is another if. The conditions are tested top to bottom and only the first true branch runs; later branches are skipped even when their conditions would also be true. A trailing else runs only when every test failed.

The condition must be boolean

The condition of an if, while, do or for must have type boolean or Boolean. Java never treats a number, a reference or null as true or false. In the table, qty is an int, open a boolean and ok a Boolean.

Assigning a boolean inside a condition is legal and has a side effect: the variable keeps the assigned value after the statement, and when the assignment sits in a loop it runs again on every test, so the variable ends up holding whatever the last test assigned. Writing = where == was meant therefore compiles silently whenever the variable is a boolean.

Unboxing a Boolean that is null throws a NullPointerException. A null check protects only the operands that are evaluated after it in the same short-circuit expression (ok != null && ok is safe, because && skips the right side when the left is false). A separate test of the same variable in a later else if is a new expression with no such protection, so it unboxes the null again.

In the traditional (colon) form, a switch statement jumps to the label that matches its selector and then keeps executing every following statement, through later labels and default, until a break or the end of the switch. That is fall-through. If nothing matches and there is no default, the switch does nothing.

public class Main {
    public static void main(String[] args) {
        for (char c : new char[] {'b', 'z', 'd'}) {
            int pts = 0;
            switch (c) {
                case 'a', 'b':
                    pts += 1;
                case 'c':
                    pts += 10;
                    break;
                default:
                    pts += 100;
                case 'd':
                    pts += 1000;
            }
            System.out.print(pts + " ");
        }
    }
}

This prints 11 1100 1000 . For 'b', execution enters at case 'a', 'b', falls into case 'c' and stops at its break. For 'z', no constant matches, so execution enters at default and falls into case 'd', the last group. For 'd', it enters at case 'd', even though default is written above it. Where default sits never changes which label is chosen — every constant is tried first, wherever it is written — it only changes which statements follow it. The last group needs no break, because the switch simply ends.

To trace a colon switch: find the entry label, then read straight down, ignoring every case and default line, until you reach a break, a return, a continue of an enclosing loop, a thrown exception or the closing brace. Several labels can share one group, either stacked (case 'a': case 'b':) or, since Java 14, as one comma-separated list (case 'a', 'b':).

An arrow label (case X ->) runs exactly one thing — the code to the right of the arrow — and then leaves the switch. There is no fall-through and no break is needed. One label can list several constants separated by commas, and default -> may appear anywhere among constant labels.

public class Main {
    static int weight(String size) {
        int w = 0;
        switch (size) {
            case "S", "XS" -> w = 1;
            case "M" -> {
                int base = 2;
                w = base * 3;
            }
            case "L" -> w += 9;
            default -> throw new IllegalArgumentException(size);
        }
        return w;
    }

    public static void main(String[] args) {
        System.out.println(weight("XS") + " " + weight("M")
            + " " + weight("L"));
        try {
            weight("XXL");
        } catch (IllegalArgumentException e) {
            System.out.println("rejected " + e.getMessage());
        }
    }
}

This prints 1 6 9 and then rejected XXL. The right-hand side of an arrow must be one of three things:

• a single expression statement — a method call, an assignment, or an increment or decrement;
• a block in braces, which may hold any statements, including local variable declarations (base above);
• a throw statement.

A local variable declaration written directly after the arrow is not an expression statement, so it fails with variable declaration not allowed here; wrap it in braces. And when two statements follow an arrow without braces, only the first belongs to the arm. The second sits loose in the switch body, where an arrow switch allows only labels, so compilation fails (case, default, or '}' expected). It never runs "as part of" the arm.

A single switch cannot mix the two label kinds. Using an arrow label and a colon label in the same switch fails with different case kinds used in the switch. Both kinds work in switch statements and in switch expressions.

In the colon form, a variable declared in one group is in scope in the groups after it, but it is only initialised on the path that ran its declaration: a later group may assign it and then read it, but reading it there before assigning fails with variable … might not have been initialized.

A switch whose labels are constants accepts a selector of type char, byte, short, int, their wrappers Character, Byte, Short, Integer, String, or an enum type. Any other reference type, such as Object or a sealed interface, needs pattern labels (next sections), or qualified enum constants such as case Level.LOW when an enum type is assignable to the selector type. long, float, double and boolean selectors do not compile in Java SE 25: javac reports that primitive patterns are a preview feature and are disabled by default, and preview features are outside the exam.

Each constant label must be a compile-time constant assignable to the selector's type, and no constant may appear twice. A compile-time constant is a literal, an enum constant, or a constant variable: a final variable of a primitive type or String whose declaration initialises it with a constant expression (literals, operators and other constants — never a method call).

On an enum selector, a label must be one of that enum's constants: a String spelling of the name, an ordinal number or the result of a method call such as valueOf is not accepted. A non-final variable is never a constant. A String switch compares with equals(), so case matters: "low" does not match "LOW".

A switch expression is a switch that produces a value, so it can sit on the right of an assignment, in a return or as an argument — and the statement that contains it still ends with a semicolon. Every way through it must either produce a value or throw. An arrow arm produces the value of its expression; a block arm, and every colon group, produces a value with yield.

public class Main {
    public static void main(String[] args) {
        for (String day : new String[] {"MON", "FRI", "THU"}) {
            int hours = switch (day) {
                case "FRI" -> 6;
                case "SUN" -> 0;
                default -> {
                    int h = 4 * 2;
                    yield h;
                }
            };
            char band = switch (day) {
                case "MON":
                    System.out.print("[start]");
                case "TUE", "WED":
                    yield 'E';
                default:
                    yield 'L';
            };
            System.out.println(day + " " + hours + band);
        }
    }
}

Output:

[start]MON 8E
FRI 6L
THU 8L

The second switch shows that colon groups still fall through inside a switch expression: "MON" prints [start] and falls into the group that yields 'E'. yield ends the switch expression with that value.

What cannot leave a switch expression

Control may not jump out of a switch expression other than by yield or throw. return inside an arm fails with attempt to return out of a switch expression; continue of an enclosing loop fails with attempt to continue out of a switch expression; and break fails with attempt to break out of a switch expression. A block arm whose last statement is neither yield nor throw, such as one ending in a bare expression, does not compile. yield is a contextual keyword: it means "produce this value" only inside a switch expression.

Exhaustiveness

A switch expression must cover every possible selector value; otherwise javac reports the switch expression does not cover all possible input values — it never silently yields null. Any of these makes it exhaustive:

• a default label (or case null, default);
• an unguarded type pattern of the selector's own type (or a supertype), such as case String other on a String selector or case Object o on an Object selector — it matches every non-null value, so no default is needed;
• for an enum, a label for every constant;
• for a sealed interface or class, a pattern for every permitted subtype.

public class Main {
    static String reply(String answer) {
        return switch (answer) {
            case "y" -> "accepted";
            case String other -> "ignored " + other;
        };
    }

    public static void main(String[] args) {
        System.out.println(reply("y") + ", " + reply("maybe"));
    }
}

This prints accepted, ignored maybe: the constant label is tried first and the unguarded case String other takes everything else. A guarded pattern (case String s when …) never counts towards exhaustiveness, because its guard may be false. The sealed form needs no default either:

public class Main {
    sealed interface Shape permits Circle, Square {}
    record Circle(double r) implements Shape {}
    record Square(double side) implements Shape {}

    static double area(Shape s) {
        return switch (s) {
            case Circle c -> Math.PI * c.r() * c.r();
            case Square q -> q.side() * q.side();
        };
    }

    public static void main(String[] args) {
        System.out.println(area(new Square(3)));
    }
}

This prints 9.0. If an enum later gains a constant, or a sealed hierarchy a subtype, and the switch is not recompiled, the unmatched value throws MatchException at run time. A null selector is a different case: it throws NullPointerException (next section).

Switch statements with only constant labels on int, String or enum selectors need not be exhaustive — values with no matching label simply run nothing. A switch statement that uses a pattern label or a case null label must be exhaustive, just like an expression.

The type of a switch expression

When the result is assigned to an explicit type, each arm must be assignable to it. When it is inferred (var, or used in a string concatenation), the type comes from the arms, using the same rules as the conditional operator ? ::

Every row was compiled and run on JDK 25. Only the arm that actually runs is evaluated, but its value is converted to the switch's type.

A switch whose selector is null throws NullPointerException unless it has a case null label — and default does not catch null. This holds for String, wrapper, enum and pattern switches, statements and expressions alike.

public class Main {
    enum Fuel { DIESEL, PETROL }

    static String tier(Integer pts) {
        return switch (pts) {
            case 0 -> "none";
            case null, default -> "some or unknown";
        };
    }

    public static void main(String[] args) {
        System.out.println(tier(null) + " / " + tier(0));
        Fuel f = null;
        try {
            switch (f) {
                case DIESEL -> System.out.println("diesel");
                default -> System.out.println("anything else");
            }
        } catch (NullPointerException e) {
            System.out.println("NullPointerException");
        }
    }
}

This prints some or unknown / none and then NullPointerException. Ways to write the null case:

• case null -> … as its own label, alongside a separate default;
• case null, default -> … — the only combination that puts default in a list, and null must come first.

A case null makes the switch an "enhanced" switch, so a switch statement on a String with one constant label and case null but no default fails: the switch statement does not cover all possible input values.

Type patterns and when guards

A type pattern label such as case Double d matches when the selector is an instance of that type and binds it to a new variable for that arm. A guard, when followed by a boolean expression, adds a condition. Labels are tried top to bottom, and the first one whose type and guard both match wins.

public class Main {
    static String classify(Object o) {
        return switch (o) {
            case Double d when d < 0 -> "negative";
            case Double d -> "double";
            case Number n -> "number " + n.intValue();
            case String s when s.isBlank() -> "blank";
            case String s -> "text";
            default -> "other";
        };
    }

    public static void main(String[] args) {
        System.out.println(classify(-1.5) + ", " + classify(2.0)
            + ", " + classify(7) + ", " + classify(" ")
            + ", " + classify('c'));
    }
}

This prints negative, double, number 7, blank, other. 7 is an Integer, which fails both Double labels and matches the broader Number pattern. 'c' is boxed to a Character, which is neither a Number nor a String, so it reaches default. A selector of type Object needs a default or an unguarded case Object x to be exhaustive. Pattern matching with instanceof and sealed hierarchies are covered further in the object-oriented lessons; here the focus is the switch.

A case label is dominated when an earlier label would always match first, so it could never run; that is a compile error, this case label is dominated by a preceding case label. The rules:

• An unguarded type pattern dominates a later pattern of the same type or a subtype: case Number n before case Double d fails; the reverse order compiles.
• A guarded pattern dominates nothing that follows, so case Double d when d > 0 before case Double d compiles — but an unguarded case Double d before the guarded one does not.
• An unguarded pattern also dominates later constant labels of its type: on a String selector, case String t before case "yes" fails.
• A guarded pattern before a constant label is legal, and then order decides: a value that satisfies the earlier guard is taken by the pattern, even when a later constant label names that value exactly.
• default dominates every pattern label after it: default -> followed by case String s fails, so put default after the patterns. (Before plain constant labels its position is free.)

Record patterns

A record pattern deconstructs a record in the label itself: case Range(int lo, int hi) matches a Range and binds its components in declaration order. Each component pattern can be a type pattern, var x (type inferred from the component), the unnamed pattern _ (matches anything, binds nothing) or another record pattern, and the label can carry a when guard.

public class Main {
    record Range(int lo, int hi) {}
    record Tagged(String tag, Object value) {}

    static String read(Object o) {
        return switch (o) {
            case Range(var lo, var hi) when hi < lo -> "empty";
            case Range(int lo, _) when lo < 0 -> "signed";
            case Range r -> "range";
            case Tagged(var t, Range(var lo, var hi)) ->
                t + ":" + (hi - lo);
            case Tagged(String t, Integer n) -> t + "=" + n;
            case Tagged(var t, _) -> t + "?";
            default -> "other";
        };
    }

    public static void main(String[] args) {
        System.out.println(read(new Range(5, 1)) + " "
            + read(new Range(-2, 3)) + " "
            + read(new Range(0, 4)) + " "
            + read(new Tagged("w", new Range(2, 9))) + " "
            + read(new Tagged("n", 3)) + " "
            + read(new Tagged("x", 1.5)));
    }
}

This prints empty signed range w:7 n=3 x?: Range(5, 1) satisfies the first guard before the second is tried, and the nested Range inside the first Tagged is deconstructed in the same label. The rules for each label:

• It lists exactly as many component patterns as the record has components; one too few fails with incorrect number of nested patterns.
• Each component pattern must be applicable to that component's declared type. A reference type pattern on an Object component, such as Integer n, is a run-time test: it matches only when the component's value is an Integer, otherwise matching moves on to the next label.
• A primitive type pattern such as int n is fine on an int component, but on an Object or Integer component it is a primitive pattern, which is a preview feature in Java 25 — it does not compile (primitive patterns are a preview feature), and unboxing does not rescue it. Write Integer n instead.
• Binding names cannot repeat within one label: reusing a name fails with illegal attempt to redefine an existing match binding.

A while loop tests its condition before each iteration, so its body may run zero times; a do-while loop tests after the body, so the body always runs at least once. A do-while ends with a semicolon after the condition.

public class Main {
    public static void main(String[] args) {
        int stock = 0;
        do {
            System.out.print("check ");
        } while (stock > 0);
        while (stock > 0) {
            System.out.print("sell ");
        }
        int tries = 5;
        while (--tries > 2)
            System.out.print(tries);
        System.out.print(" " + tries + " | ");
        int left = 5;
        while (left-- > 2)
            System.out.print(left);
        System.out.println(" " + left);
    }
}

This prints check 43 2 | 432 1. The do-while body runs once although stock > 0 is false, and the while body never runs. In --tries > 2 the decrement happens first and the comparison uses the new value, so the body sees 4 and 3, and the loop stops with tries at 2. In left-- > 2 the comparison uses the old value and the decrement happens anyway: the body sees 4, 3 and 2, and the final failing test (2 > 2) still decrements left to 1. Prefix and postfix forms in a condition shift both the printed values and the final value, so trace every test explicitly — including the last, failing one.

A variable declared inside a do block is out of scope in its while condition: a block that declares boolean again followed by while (again); fails with cannot find symbol. Declare the variable before the loop when the condition needs it.

A basic for loop has three parts: the initializer runs once, the condition is tested before every iteration (including the first), and the update runs after every completed body, followed by the next test. Any part may be empty, and for (;;) loops forever.

public class Main {
    static int n = 3;

    static boolean more() {
        System.out.print("?");
        return n > 1;
    }

    public static void main(String[] args) {
        for (System.out.print("<"); more(); n--)
            System.out.print(n);
        System.out.println();
        for (int lo = 1, hi = 9; lo <= hi; lo *= 2, hi--)
            System.out.print(lo + "-" + hi + " ");
    }
}

The first loop prints <?3?2?: one initializer, then test-body-update twice, then a final failing test. The second prints 1-9 2-8 4-7 — after the third update lo is 8 and hi is 6, and 8 <= 6 is false. The initializer may declare several variables of one type (int lo = 1, hi = 9) or list expression statements; declaring variables of two different types in one initializer does not compile. The update may list several expression statements separated by commas. Changing the loop variable inside the body also changes what the update and the next test see, so trace the body's change and the update together on each pass.

Loop-variable scope

A variable declared in the initializer exists only inside the loop. After the loop ends, the same name can be declared again — in another loop or as an ordinary local. It cannot be declared while a local of the same name is still in scope: with int idx already declared in the method, for (int idx = 0; …) fails with variable idx is already defined, whereas an initializer that only assigns the existing variable (idx = 0, with no type) reuses it. A loop variable cannot be read after the loop either. A variable declared in the body is created fresh, with its initializer run again, on every iteration.

The enhanced for loop

The enhanced for loop, for (Type v : source), visits each element of an array or of any Iterable (a List, a Set …) in order. The loop variable holds a copy of each element. Reassigning the variable changes nothing in the array or collection. But when the element is a reference, the copy points at the same object, so changing that object — by a method call, or by assigning to one of its fields or, for an inner array, one of its elements — changes the object the array or collection holds.

public class Main {
    static class Cell {
        int v;
        Cell(int v) { this.v = v; }
    }

    public static void main(String[] args) {
        double[] prices = {1.5, 2.5};
        for (double p : prices) {
            p = p * 2;
        }
        Cell[] cells = {new Cell(1), new Cell(2)};
        for (Cell c : cells) {
            c.v += 5;
            c = new Cell(0);
        }
        System.out.println(prices[0] + " " + prices[1] + " "
            + cells[0].v + " " + cells[1].v);
    }
}

This prints 1.5 2.5 6 7: doubling the copy p leaves the array alone, the assignment c.v += 5 writes through the copy into each shared Cell, and the later c = new Cell(0) only redirects the copy. The same applies to an array of arrays: assigning an element of the inner array changes the grid, assigning a new array to the loop variable does not.

The loop variable's declared type must accept each element: the element type, a supertype of it, or var (which infers the element type) all work, while an unrelated type does not compile. The source must be an array or an Iterable; an Iterator or a Stream is neither (for-each not applicable to expression type). The variable may be declared final, which forbids assigning to it in the body.

break ends the innermost enclosing loop or switch; continue skips the rest of the current iteration of the innermost loop and goes to its next test (in a for loop, the update runs first). A label (find:) names a statement so a nested break find leaves that statement, and continue find starts the labelled loop's next iteration.

public class Main {
    public static void main(String[] args) {
        int[][] grid = {{4, 1, 8}, {6, 2, 9}, {10}};
        find:
        for (int[] row : grid) {
            for (int v : row) {
                if (v % 2 == 1) continue find;
                if (v < 3) break find;
                System.out.print(v + " ");
            }
        }
        System.out.println();
        String out = "";
        for (char ch : "go-on!".toCharArray()) {
            switch (ch) {
                case '-' -> {
                    continue;
                }
                case '!' -> {
                    break;
                }
                default -> out += Character.toUpperCase(ch);
            }
            out += "|";
        }
        System.out.println(out);
    }
}

Output: 4 6 and then G|O|O|N||. In the grid, the odd 1 sends control to the next row (so 8 is skipped), and the 2 in the second row ends both loops, so the last row is never visited. In the second loop, continue inside the switch skips straight to the next character, so '-' gets no bar, while break leaves only the switch, so '!' still gets its "|". The same is true in colon switches. Remember that continue (and break) can never jump out of a switch expression.

• break label works with any labelled statement, including a plain block: guard: { … break guard; … } skips the rest of the block and carries on after it.
• continue label needs a labelled loop; using it with the label of a block, or of any other statement that is not a loop, fails with not a loop label.
• A label is only visible inside the statement it labels. A break or continue naming a label that does not enclose it fails with undefined label, even when that label exists elsewhere in the method.

Unreachable statements

javac rejects a statement it can prove can never run, with unreachable statement. For loops, the analysis treats only constant expressions specially; every other condition is assumed to be possibly true and possibly false.

A break that only leaves a switch inside an infinite loop does not count — the loop still cannot complete, so a statement after it is unreachable. A return inside the body does not make the loop completable either. The same analysis decides whether a method with a return type needs a final return: a body that ends in an infinite loop with no break can never fall off the end, so it needs none, but a loop with a non-constant condition might finish, so the method then fails with missing return statement unless a return follows the loop.