Java Decision-Making Statements: Choosing Which Code Runs

Java gives you four decision-making constructs, and the choice between them comes down to what shape your condition has rather than to any preference about style.

The distinction in the last column is the important one and it drives everything else. An if is a **statement**, so it performs an action and yields nothing. A switch used in expression form is an **expression**, so it produces a value you can assign, return, or pass along.

if (temperature > 30) {
    System.out.println("Hot");
    // performs an action
}String label = switch (temperature) {
    // produces a value
    default -> "thawing";
};

This is the first thing that catches people arriving from C or C++, where if (1) is legal because any nonzero value counts as true. Java has no such rule.

if (1) {
} // error: incompatible types: int cannot be converted to boolean
if (str) {
} // error: incompatible types: String cannot be converted to boolean

The rule applies to every conditional construct, and it is a compile error rather than a runtime surprise, which is the kind way to learn it.

int count = items.size();
if (count) {
} // error
if (count > 0) {
} // correct, say what you mean

That last line is worth internalising as a style point too. if (count > 0) says something to the next reader even though if (count != 0) would compile.

The Boolean wrapper is the exception, and it is a trap rather than a convenience.

Boolean flag = null;
if (flag) {
} // throws NullPointerException on unboxing

Because a Boolean has to be unboxed before it can be tested, and unboxing null throws. Use a primitive boolean, or guard with flag != null && flag.

The basic if needs nothing else, and is the right choice when there is genuinely only one thing to check.

if (temperature > 30) {
    System.out.println("Hot weather");
}

Adding else gives you two exclusive paths, and the two are guaranteed to be mutually exclusive because only one runs.

if (temperature > 30) {
    System.out.println("Hot");
} else {
    System.out.println("Not hot");
}

A ladder extends this to many conditions, and the crucial detail is that it is tested **in order**, so the first match wins and everything after it is skipped.

if (temperature > 30) {
    System.out.println("Hot");
} else if (temperature >= 20) {
    System.out.println("Pleasant");
} else {
    System.out.println("Cold");
}

With temperature of 28 the first test fails and the second matches, so the output is Pleasant and the else never runs. That ordering matters whenever the conditions overlap.

// order changed, and the answer changes with it
if (temperature >= 20) {
    System.out.println("Pleasant");
    // now this matches first
} else if (temperature > 30) {
    System.out.println("Hot");
    // now unreachable for 28
}

A switch matches a single value against a set of cases, which suits discrete choices rather than ranges.

switch (day) {
    case "MON": case "TUE": System.out.println("Week start");
    break;
    default: System.out.println("Midweek");
}

Note the stacked cases. In the traditional form, falling from one case into the next is **intentional** and is how you group several values into one branch.

An else always attaches to the **nearest** unmatched if, which matters only when you leave the braces off.

if (x == 0) if (x == 1) System.out.println("both");
else System.out.println("else binds to the inner if");

The else belongs to the inner if, not the outer one, because the inner if is the closest one without an else. When x is 0 the output is the second line, since the inner condition fails and its else runs.

With braces the structure is unambiguous and the nesting reads the way it actually works.

if (x == 0) {
    if (x == 1) {
        System.out.println("both");
    } else {
        System.out.println("inner else");
    }
}

The rule is simply to always use braces, even for a single statement. Modern style makes the braceless form rare for exactly this reason.

else attaches to the NEAREST if above it if (a) -> outer if, has no else of its own if (b) -> inner if, unmatched ...;
else -> therefore binds to the INNER if braces remove the question entirely, and cost one keystroke

A variable declared inside a branch belongs to that branch, and the compiler will not let you use it outside. This is stricter than the "leaky" scoping of old C.

if (temperature > 30) {
    int message = "Hot weather";
    System.out.println(message);
    // fine inside
}System.out.println(message);
// error: cannot find symbol

The declaration's scope is the block it appears in, so the same name can be reused in a different block without conflict.

if (temperature > 30) {
    int temp = 100;
    System.out.println(temp);
}if (temperature < 0) {
    int temp = -273;
    // a different variable, no clash
    System.out.println(temp);
}

That is convenient, but it also means a name reused in two branches can refer to two different values, so a repeated name is worth avoiding when the branches are related.

If you declare a variable without initialising it, the compiler requires proof that it has a value before you read it. Every path through the branches must assign it.

int result;
if (temperature > 30) {
    result = 1;
} else {
    result = 2;
}System.out.println(result);
// fine, both paths assign

Omit the else and the compiler rejects the read, because there is a path that leaves result unassigned.

int result;
if (temperature > 30) {
    result = 1;
}System.out.println(result);
// error: variable result might not have been initialized

This is a genuine safety net rather than an inconvenience. The error message names the exact problem, and it catches the classic bug where an unhandled branch leaves a variable at zero or null.

String name = null;
if (temperature > 30) {
    name = "Hot";
}System.out.println(name.length());
// rejected, not silently a NullPointerException later

Assigning a default up front is the other way to satisfy it, and is often clearer when zero or null is a sensible value.

int result = 0;
if (temperature > 30) {
    result = 1;
}

A ladder with one return per branch is functionally identical to a ladder of if blocks, but it reads better because each condition sits at the same indentation and there is no nested block to track.

// nested
String grade;
if (score >= 0) {
    if (score < 50) {
        grade = "F";
    } else {
        grade = "pass";
    }
} else {
    grade = "invalid";
}// guard clauses
String grade;
if (score < 0) grade = "invalid";
else if (score < 50) grade = "F";
else grade = "pass";

The **early return** form is best of all when the function has nothing left to do after the decision, since it removes the variable entirely.

static String grade(int score) {
    if (score < 50) return "F";
    if (score < 70) return "C";
    if (score < 90) return "B";
    return "A";
}

The condition that should be checked first goes first, and each one is independent, so there is no nesting to reason about. This is the single most effective readability technique for conditionals.

The traditional switch **statement** executes statements and needs a break to avoid falling into the next case.

int n = 2;
switch (n) {
    case 1: System.out.println("one");
    case 2: System.out.println("two");
    case 3: System.out.println("three");
    break;
    case 4: System.out.println("four");
}

That prints two **and** three, because there is no break after case 2 and execution falls through. This is legal, occasionally deliberate, and a very common source of bugs.

fall-through in the traditional form case 2 has no break -> prints two, then continues into case 3 deliberate use: case 1: case 2: case 3: share one body accidental use: forgot the break

The **arrow form** has no fall-through, so break is neither needed nor allowed, and it produces a value.

String s = switch (n) {
    case 1 -> "one";
    case 2 -> "two";
    default -> "many";
};
System.out.println(s);
// two

Several values can share a case with a comma, which removes the stacking that the traditional form needs.

String band = switch (n) {
    case 0, 1, 2 -> "low";
    default -> "high";
};

When a case needs more than one statement, use a block and yield to say what the value is.

int v = switch (n) {
    case 1 -> 10;
    case 2 -> {
        int doubled = 20;
        yield doubled * 2;
    } default -> 0;
};

A switch used as an expression must be **exhaustive**, or the compiler refuses it.

String r = switch (n) {
    case 1 -> "one";
    // no default
};
// error: the switch expression does not cover all possible input values

Adding default fixes it, and that requirement is a feature: it means the compiler has checked that you handled every case.

A switch on a String compares using equals, not ==. This is the opposite of how strings behave with the equality operator, and it is the behaviour you would want.

String day = new String("MON");
switch (day) {
    case "MON": System.out.println("Monday");
    break;
    default: System.out.println("?");
}// prints Monday, even though day came from new String

If you had written this with if, you would need day.equals("MON") or Objects.equals, because day == "MON" would be false. The switch case label does the right thing for you.

// the equivalent if, note what it takes
if ("MON".equals(day)) {
    ...
}

A switch on an enum is the clearest case of all, and an enum without a matching case simply falls to default.

Thread.State state = Thread.State.NEW;
switch (state) {
    case NEW: System.out.println("new thread");
    break;
    case RUNNABLE: System.out.println("running");
    break;
    default: System.out.println("other");
}

The selector of a switch must be one of a small set of types. Exactly these compile.

The gap between the integer types is the one that bites, since int is allowed but long is not and the two look like a pair.

switch (someInt) {
} // fine
switch (someLong) {
} // rejected, long is not a valid selector

If you need to switch on a long, an if-else ladder or a lookup map is the honest answer.

The traditional way to test a type and then use it required two steps, because the compiler would not let you cast inside the if.

Object o = "hello";
if (o instanceof String) {
    String s =(String) o;
    // an explicit cast that could fail
    System.out.println(s.length());
}

Pattern matching, final since Java 16, merges the test and the binding into one step and makes the cast unnecessary.

if (o instanceof String s) {
    System.out.println(s.length());
    // s is already a String
}

The variable s is in scope **only** where the test succeeded, which is exactly the safety the two-step version was missing.

Object p = 42;
if (p instanceof String s) {
    System.out.println("unreachable");
} else {
    System.out.println("s is not in scope here");
}

This pairs naturally with && for a combined type and content test, which is where the null-safe comparison idiom from the ternary topic comes from.

if (name instanceof String s && s.length() > 3) {
    System.out.println("a string of some length: " + s);
}

Note that pattern matching in switch is a **separate and newer feature**. It is standard from Java 21, but on Java 17 it is still a preview feature, so code using case Integer i -> will not compile on 17 without --enable-preview.

// Java 21 and later
String describe(Object o) {
    return switch (o) {
        case Integer i when i > 100 -> "big int";
        case Integer i -> "int";
        case String s -> "string";
        default -> "something else";
    };
}// on Java 17 the same code reports
// patterns in switch statements are a preview feature and are disabled by default

A short decision guide, based on the shape of the condition rather than on style.

The most common mistake is reaching for a switch when the conditions are ranges, or for a ladder when the values are discrete.

// a switch cannot express a range, this belongs in an if
if (score >= 90) {
    ...
}// a ladder of exact values is exactly what switch is for
switch (status) {
    case 1 -> ...;
    case 2 -> ...;
}

Each of these is a real failure mode rather than a style opinion.

The ladder ordering bug is the subtlest of these, since it compiles and runs and simply produces the wrong answer.

// wrong order, the broad test shadows the narrow one
if (score > 50) System.out.println("passed");
else if (score > 90) System.out.println("excellent");
// a score of 95 prints passed, never excellent

The one-line version: reach for if when you are testing a condition, for a ladder when you are testing ordered ranges, and for a switch expression when you are matching one value against a set and want a result back. Guard clauses are what keep all three readable, because they keep the nesting flat and let each condition say one thing.