if…else

Kurz: Erweitert das einfache if-Statement um einen Alternativzweig, der läuft, wenn die Bedingung false ist.

Genauer: Mehrere Bedingungen lassen sich mit else if verketten (siehe else…if), am Ende fängt ein abschließendes else (ohne eigene Bedingung) alle übrigen Fälle auf. Für einfache Wert-Entscheidungen bietet Java zusätzlich den ternären Operator als Kurzform: int x = bedingung ? a : b;.

if (note <= 4) {
    System.out.println("Bestanden");
} else {
    System.out.println("Nicht bestanden");
}

Im Detail

int note = 5;
if (note <= 4) {
    System.out.println("Bestanden");
} else {
    System.out.println("Nicht bestanden");
}
 
// Ternärer Operator - kompakte Alternative für einfache Wert-Entscheidungen
String ergebnis = (note <= 4) ? "Bestanden" : "Nicht bestanden";
 
// Verschachtelt (Vorsicht: schnell unübersichtlich)
String kategorie = (note <= 2) ? "Gut" : (note <= 4) ? "Bestanden" : "Nicht bestanden";

Der ternäre Operator (bedingung ? wertWennTrue : wertWennFalse) ist syntaktisch ein AUSDRUCK, kein Statement — er liefert direkt einen Wert und lässt sich deshalb z. B. direkt einer Variable zuweisen oder als Methodenargument übergeben, was mit einem vollständigen if...else-Block nicht ohne Weiteres geht. Für einfache Ja/Nein-Wertentscheidungen ist er kompakter und wird von vielen als lesbarer empfunden; bei mehr als einer verschachtelten Bedingung kippt das aber schnell ins Gegenteil, und ein ausgeschriebenes if...else bzw. Switch-Statement bleibt klarer.

Das “Dangling Else”-Problem

Ohne geschweifte Klammern kann ein else mehrdeutig werden, WELCHEM if es zugeordnet ist — Java löst das (wie die meisten C-artigen Sprachen) so auf, dass ein else immer zum NÄCHSTGELEGENEN offenen if gehört, was oft nicht der Intuition entspricht:

if (a > 0)
    if (b > 0)
        System.out.println("beide positiv");
else // gehört zum inneren if(b > 0), NICHT zum äußeren if(a > 0)!
    System.out.println("b nicht positiv");

Bei a <= 0 wird hier GAR NICHTS ausgegeben, obwohl die Einrückung suggeriert, das else gehöre zum äußeren if. Genau deshalb gilt es in praktisch jedem Java-Styleguide als Best Practice, bei verschachtelten Bedingungen immer geschweifte Klammern zu setzen, auch wenn der Block nur eine Zeile enthält — das macht die Zuordnung eindeutig und für den Compiler UND für Menschen lesbar gleich.

if ohne else — und wann es fehlt

Ein if ganz ohne else ist völlig normal, wenn im negativen Fall einfach nichts passieren soll. Häufiger Anfängerfehler ist allerdings, ein else zu VERGESSEN, wo eigentlich eine Alternative nötig wäre — z. B. eine Validierung, die bei ungültiger Eingabe schweigend weiterläuft, statt einen Fehler zu melden. Ein Blick darauf, ob wirklich ALLE möglichen Fälle abgedeckt sind (auch der “unwahrscheinliche”), gehört zu den Standard-Debugging-Fragen bei unerwartetem Programmverhalten.

Pattern Matching für instanceof

Seit Java 16 lässt sich eine if-Bedingung mit instanceof direkt mit einer Typ-Variable kombinieren, die im if-Zweig automatisch nutzbar ist, ohne manuellen Cast:

Object o = "Ein Text";
if (o instanceof String s) { // s ist ab hier automatisch vom Typ String
    System.out.println(s.length());
} else {
    System.out.println("Kein String");
}

Vor Java 16 musste man nach einer instanceof-Prüfung noch manuell casten (String s = (String) o;) — eine zusätzliche Zeile, die sich leicht vergessen oder mit dem falschen Typ schreiben ließ.

Siehe auch: if-Statement, else…if