try, catch, finally — wie reagiert dein Programm auf Fehler ohne abzustürzen? Exception-Hierarchie, Checked vs. Unchecked, eigene Exceptions, try-with-resources. Mit Try-Catch-Simulator und 4 Live-Snippets.
Eine Exception ist ein Laufzeit-Fehler der den normalen Programmablauf unterbricht. Mit try-catch fängst du sie ab und reagierst kontrolliert statt das Programm crashen zu lassen. Pflichtthema in Java-Klausuren, in Python ähnlich aber lockerer.
Was du in der Klausur können musst:
In Klausuren oft gefragt: welche Ausgabe produziert dieser Code? wenn eine Exception in try-catch-finally fließt. Wichtig: finally läuft auch wenn try ein return macht, das ist die häufigste Falle. Plus die typischen Exceptions: NullPointerException, ArrayIndexOutOfBoundsException, NumberFormatException, ArithmeticException.
Du schreibst:
int a = 10, b = 0;
int result = a / b; // ⚠ ArithmeticException: / by zero
System.out.println(result);
Was passiert? Java stürzt ab. Der Stack-Trace wird gedruckt, das Programm endet, alles danach läuft nicht.
Eine Exception ist ein außergewöhnliches Ereignis, das den normalen Programmfluss unterbricht.
Mit Exception Handling kannst du das abfangen und reagieren statt abzustürzen.
try {
// Code, der eine Exception werfen könnte
int result = a / b;
System.out.println(result);
} catch (ArithmeticException e) {
// Diese Exception abfangen und behandeln
System.out.println("Division durch 0!");
} finally {
// Wird IMMER ausgeführt — egal ob Exception oder nicht
System.out.println("Aufräumen");
}
Drei Möglichkeiten wie der Code laufen kann:
finally läuft IMMER — auch wenn die Exception nicht abgefangen wird. Das ist der Sinn: Aufräumen sicherstellen.
Gleiche Idee, andere Wörter:
try:
result = a / b
print(result)
except ZeroDivisionError as e:
print("Division durch 0!")
except Exception as e:
print(f"Anderer Fehler: {e}")
finally:
print("Aufräumen")
except statt catch, sonst gleich. Python hat zusätzlich else (läuft wenn KEIN Fehler kam, aber nach try).
In Java sind alle Exceptions Klassen, die voneinander erben:
Throwable
/ \
Error Exception
(nicht |
catchen!) |
┌─────────┴────────┐
IOException RuntimeException
SQLException / | \
... NullPointer Arithmetic ArrayIndex
Exception Exception OutOfBounds
Throwable ist die Wurzel. Du kannst alles "throwbare" mit
catch (Throwable e)abfangen — solltest du aber nie.
In Java zentral wichtig:
| Typ | Beispiele | Pflicht? |
|---|---|---|
| Checked (unter Exception, NICHT RuntimeException) | IOException, SQLException | MUSS behandelt werden (catch oder throws-Deklaration) |
| Unchecked (RuntimeException + Subklassen) | NullPointer, Arithmetic, ArrayIndex | darf behandelt werden, aber muss nicht |
| Error | OutOfMemoryError, StackOverflowError | NICHT abfangen — JVM-Probleme |
Checked = Compiler zwingt dich. Wenn du eine Methode aufrufst, die eine IOException werfen kann, MUSST du sie entweder mit try/catch fangen oder mit
throwsweiterreichen.
// Checked Exception — Compiler verlangt Behandlung
public void readFile() throws IOException {
Files.readString(path); // wirft IOException
}
// Aufrufer muss reagieren:
try {
readFile();
} catch (IOException e) {
e.printStackTrace();
}
In Python gibt es keinen Checked/Unchecked-Unterschied — alle Exceptions sind unchecked. Du kannst, musst aber nicht fangen.
Du kannst mehrere catch-Blöcke hintereinander setzen — Java probiert sie von oben nach unten durch und nimmt den ersten passenden:
try {
// ...
} catch (ArithmeticException e) { // spezifisch
System.out.println("Math-Fehler");
} catch (NullPointerException e) { // spezifisch
System.out.println("Null-Fehler");
} catch (Exception e) { // Fallback
System.out.println("Anderer Fehler");
}
Reihenfolge matters: spezifische Exceptions zuerst, generelle zuletzt. Sonst Compile-Fehler ("Exception already caught").
Wenn die Behandlung gleich ist, mehrere Typen kombinierbar:
try {
// ...
} catch (IOException | SQLException e) {
System.out.println("I/O oder DB-Fehler: " + e.getMessage());
}
Manchmal willst du selbst eine Exception auslösen — z.B. bei ungültigen Argumenten:
public void setAlter(int alter) {
if (alter < 0) {
throw new IllegalArgumentException("Alter darf nicht negativ sein: " + alter);
}
this.alter = alter;
}
def set_alter(self, alter):
if alter < 0:
raise ValueError(f"Alter darf nicht negativ sein: {alter}")
self.alter = alter
Du kannst auch eigene Exception-Typen definieren:
public class UngültigeNoteException extends Exception {
public UngültigeNoteException(double note) {
super("Note " + note + " ist außerhalb 1.0–6.0");
}
}
// Nutzung
public void setNote(double note) throws UngültigeNoteException {
if (note < 1.0 || note > 6.0) {
throw new UngültigeNoteException(note);
}
}
Eigene Exceptions sind sinnvoll wenn: domänenspezifische Fehler, klare Semantik, oft mit zusätzlichen Daten.
Klausur-Klassiker. Bei Ressourcen (Datei, DB-Verbindung, Stream) MUSS man hinterher schließen — auch im Fehlerfall.
Alte Methode (Java vor 7):
FileReader fr = null;
try {
fr = new FileReader("data.txt");
// arbeit damit...
} finally {
if (fr != null) fr.close(); // muss in finally!
}
Neu (try-with-resources):
try (FileReader fr = new FileReader("data.txt")) {
// arbeit damit...
}
// fr.close() wird AUTOMATISCH aufgerufen — auch bei Exception
Voraussetzung: die Ressource muss
AutoCloseableimplementieren. Viele Standard-Klassen tun das (Reader, Writer, Stream, Connection).
In Python macht das with:
with open("data.txt") as f:
# arbeit damit...
# f.close() wird AUTOMATISCH aufgerufen
try {
// 200 Zeilen Code
} catch (Exception e) {
// alles still abfangen
}
So versteckst du Bugs. Du weißt nie was schief lief.
try {
// ...
} catch (IOException e) {
// do nothing ← BAD
}
Mindestens loggen. Sonst verschwindet der Fehler spurlos.
try {
Files.write(path, data);
} catch (FileNotFoundException e) {
// Datei nicht da → Default benutzen
} catch (IOException e) {
// anderes I/O-Problem → höher melden
throw new RuntimeException("I/O-Fehler", e);
}
Nur die Zeile in try, die die Exception werfen kann. Nicht 100 Zeilen.
// SCHLECHT — Exception zur Kontrollfluss-Steuerung
try {
int x = Integer.parseInt(s);
return x;
} catch (NumberFormatException e) {
return 0; // "wenn nicht parsable, dann 0"
}
// BESSER — vorher prüfen
if (s.matches("-?\\d+")) {
return Integer.parseInt(s);
}
return 0;
Exceptions sind teuer (Stack-Trace zusammenbauen). Für normale Logik nicht geeignet.
Trick 1 — finally läuft IMMER: auch wenn Exception nicht abgefangen wird. Auch wenn return im try steht. Auch wenn in catch eine neue Exception fliegt. (Ausnahme: System.exit() oder JVM-Crash.)
Trick 2 — Reihenfolge der catch-Blöcke: spezifisch → generell. catch (Exception e) als erstes wäre Compile-Fehler.
Trick 3 — Checked vs. Unchecked:
Trick 4 — try ohne catch geht in Java NICHT. Man braucht entweder catch oder finally (oder beides). try { ... } allein → Compile-Fehler.
Trick 5 — Exception fortpflanzen: wenn du sie nicht fangen willst, mit throws deklarieren:
public void method() throws IOException { // Aufrufer muss kümmern
Files.readString(path);
}
Trick 6 — Cause behalten: wenn du in catch eine neue Exception wirfst, wickle die alte ein:
catch (IOException e) {
throw new RuntimeException("I/O-Problem beim Laden", e); // 'e' als cause
}
Sonst geht der ursprüngliche Stack-Trace verloren.
Trick 7 — Exception in finally: wenn finally selbst eine Exception wirft, überschreibt sie eine eventuelle Exception aus dem try-Block. Verhindern: Logik in finally robust halten.
Trick 8 — try-with-resources Reihenfolge: ressourcen werden in umgekehrter Reihenfolge geschlossen.
try (A a = ...; B b = ...) {
// schließt b, dann a
}
Trick 9 — Exception oder Error?:
Faustregel: an jeder System-Grenze (Datei, Netzwerk, DB) gehört Exception-Handling. Innerhalb deiner eigenen Logik: nur wenn nötig, lieber vorher prüfen.
Alle Tabs der Lerneinheit (Erklärung · Interaktiv · Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur — und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).
Eine Exception ist ein Laufzeit-Fehler der den normalen Programmablauf unterbricht. Mit try-catch fängst du sie ab und reagierst kontrolliert statt das Programm crashen zu lassen. Pflichtthema in Java-Klausuren, in Python ähnlich aber lockerer.
Wie speichert ein Programm Werte? Wie unterscheiden sich int, double, String und boolean?
if, else, else if. Wie trifft ein Programm Entscheidungen, und welche Vergleichsoperatoren brauchst du?
for, while, Iteration. Wie wiederhole ich Code, ohne mich zu verzetteln?
Was du in der Klausur können musst:
In Klausuren oft gefragt: welche Ausgabe produziert dieser Code? wenn eine Exception in try-catch-finally fließt. Wichtig: finally läuft auch wenn try ein return macht, das ist die häufigste Falle. Plus die typischen Exceptions: NullPointerException, ArrayIndexOutOfBoundsException, NumberFormatException, ArithmeticException.
Du schreibst:
int a = 10, b = 0;
int result = a / b; // ⚠ ArithmeticException: / by zero
System.out.println(result);
Was passiert? Java stürzt ab. Der Stack-Trace wird gedruckt, das Programm endet, alles danach läuft nicht.
Eine Exception ist ein außergewöhnliches Ereignis, das den normalen Programmfluss unterbricht.
Mit Exception Handling kannst du das abfangen und reagieren statt abzustürzen.
try {
// Code, der eine Exception werfen könnte
int result = a / b;
System.out.println(result);
} catch (ArithmeticException e) {
// Diese Exception abfangen und behandeln
System.out.println("Division durch 0!");
} finally {
// Wird IMMER ausgeführt — egal ob Exception oder nicht
System.out.println("Aufräumen");
}
Drei Möglichkeiten wie der Code laufen kann:
finally läuft IMMER — auch wenn die Exception nicht abgefangen wird. Das ist der Sinn: Aufräumen sicherstellen.
Gleiche Idee, andere Wörter:
try:
result = a / b
print(result)
except ZeroDivisionError as e:
print("Division durch 0!")
except Exception as e:
print(f"Anderer Fehler: {e}")
finally:
print("Aufräumen")
except statt catch, sonst gleich. Python hat zusätzlich else (läuft wenn KEIN Fehler kam, aber nach try).
In Java sind alle Exceptions Klassen, die voneinander erben:
Throwable
/ \
Error Exception
(nicht |
catchen!) |
┌─────────┴────────┐
IOException RuntimeException
SQLException / | \
... NullPointer Arithmetic ArrayIndex
Exception Exception OutOfBounds
Throwable ist die Wurzel. Du kannst alles "throwbare" mit
catch (Throwable e)abfangen — solltest du aber nie.
In Java zentral wichtig:
| Typ | Beispiele | Pflicht? |
|---|---|---|
| Checked (unter Exception, NICHT RuntimeException) | IOException, SQLException | MUSS behandelt werden (catch oder throws-Deklaration) |
| Unchecked (RuntimeException + Subklassen) | NullPointer, Arithmetic, ArrayIndex | darf behandelt werden, aber muss nicht |
| Error | OutOfMemoryError, StackOverflowError | NICHT abfangen — JVM-Probleme |
Checked = Compiler zwingt dich. Wenn du eine Methode aufrufst, die eine IOException werfen kann, MUSST du sie entweder mit try/catch fangen oder mit
throwsweiterreichen.
// Checked Exception — Compiler verlangt Behandlung
public void readFile() throws IOException {
Files.readString(path); // wirft IOException
}
// Aufrufer muss reagieren:
try {
readFile();
} catch (IOException e) {
e.printStackTrace();
}
In Python gibt es keinen Checked/Unchecked-Unterschied — alle Exceptions sind unchecked. Du kannst, musst aber nicht fangen.
Du kannst mehrere catch-Blöcke hintereinander setzen — Java probiert sie von oben nach unten durch und nimmt den ersten passenden:
try {
// ...
} catch (ArithmeticException e) { // spezifisch
System.out.println("Math-Fehler");
} catch (NullPointerException e) { // spezifisch
System.out.println("Null-Fehler");
} catch (Exception e) { // Fallback
System.out.println("Anderer Fehler");
}
Reihenfolge matters: spezifische Exceptions zuerst, generelle zuletzt. Sonst Compile-Fehler ("Exception already caught").
Wenn die Behandlung gleich ist, mehrere Typen kombinierbar:
try {
// ...
} catch (IOException | SQLException e) {
System.out.println("I/O oder DB-Fehler: " + e.getMessage());
}
Manchmal willst du selbst eine Exception auslösen — z.B. bei ungültigen Argumenten:
public void setAlter(int alter) {
if (alter < 0) {
throw new IllegalArgumentException("Alter darf nicht negativ sein: " + alter);
}
this.alter = alter;
}
def set_alter(self, alter):
if alter < 0:
raise ValueError(f"Alter darf nicht negativ sein: {alter}")
self.alter = alter
Du kannst auch eigene Exception-Typen definieren:
public class UngültigeNoteException extends Exception {
public UngültigeNoteException(double note) {
super("Note " + note + " ist außerhalb 1.0–6.0");
}
}
// Nutzung
public void setNote(double note) throws UngültigeNoteException {
if (note < 1.0 || note > 6.0) {
throw new UngültigeNoteException(note);
}
}
Eigene Exceptions sind sinnvoll wenn: domänenspezifische Fehler, klare Semantik, oft mit zusätzlichen Daten.
Klausur-Klassiker. Bei Ressourcen (Datei, DB-Verbindung, Stream) MUSS man hinterher schließen — auch im Fehlerfall.
Alte Methode (Java vor 7):
FileReader fr = null;
try {
fr = new FileReader("data.txt");
// arbeit damit...
} finally {
if (fr != null) fr.close(); // muss in finally!
}
Neu (try-with-resources):
try (FileReader fr = new FileReader("data.txt")) {
// arbeit damit...
}
// fr.close() wird AUTOMATISCH aufgerufen — auch bei Exception
Voraussetzung: die Ressource muss
AutoCloseableimplementieren. Viele Standard-Klassen tun das (Reader, Writer, Stream, Connection).
In Python macht das with:
with open("data.txt") as f:
# arbeit damit...
# f.close() wird AUTOMATISCH aufgerufen
try {
// 200 Zeilen Code
} catch (Exception e) {
// alles still abfangen
}
So versteckst du Bugs. Du weißt nie was schief lief.
try {
// ...
} catch (IOException e) {
// do nothing ← BAD
}
Mindestens loggen. Sonst verschwindet der Fehler spurlos.
try {
Files.write(path, data);
} catch (FileNotFoundException e) {
// Datei nicht da → Default benutzen
} catch (IOException e) {
// anderes I/O-Problem → höher melden
throw new RuntimeException("I/O-Fehler", e);
}
Nur die Zeile in try, die die Exception werfen kann. Nicht 100 Zeilen.
// SCHLECHT — Exception zur Kontrollfluss-Steuerung
try {
int x = Integer.parseInt(s);
return x;
} catch (NumberFormatException e) {
return 0; // "wenn nicht parsable, dann 0"
}
// BESSER — vorher prüfen
if (s.matches("-?\\d+")) {
return Integer.parseInt(s);
}
return 0;
Exceptions sind teuer (Stack-Trace zusammenbauen). Für normale Logik nicht geeignet.
Trick 1 — finally läuft IMMER: auch wenn Exception nicht abgefangen wird. Auch wenn return im try steht. Auch wenn in catch eine neue Exception fliegt. (Ausnahme: System.exit() oder JVM-Crash.)
Trick 2 — Reihenfolge der catch-Blöcke: spezifisch → generell. catch (Exception e) als erstes wäre Compile-Fehler.
Trick 3 — Checked vs. Unchecked:
Trick 4 — try ohne catch geht in Java NICHT. Man braucht entweder catch oder finally (oder beides). try { ... } allein → Compile-Fehler.
Trick 5 — Exception fortpflanzen: wenn du sie nicht fangen willst, mit throws deklarieren:
public void method() throws IOException { // Aufrufer muss kümmern
Files.readString(path);
}
Trick 6 — Cause behalten: wenn du in catch eine neue Exception wirfst, wickle die alte ein:
catch (IOException e) {
throw new RuntimeException("I/O-Problem beim Laden", e); // 'e' als cause
}
Sonst geht der ursprüngliche Stack-Trace verloren.
Trick 7 — Exception in finally: wenn finally selbst eine Exception wirft, überschreibt sie eine eventuelle Exception aus dem try-Block. Verhindern: Logik in finally robust halten.
Trick 8 — try-with-resources Reihenfolge: ressourcen werden in umgekehrter Reihenfolge geschlossen.
try (A a = ...; B b = ...) {
// schließt b, dann a
}
Trick 9 — Exception oder Error?:
Faustregel: an jeder System-Grenze (Datei, Netzwerk, DB) gehört Exception-Handling. Innerhalb deiner eigenen Logik: nur wenn nötig, lieber vorher prüfen.
Wähle einen der vier Code-Snippets und sieh Schritt-für-Schritt, wie der Kontrollfluss läuft:
Probier folgendes:
Klick Step für manuelles Durchlaufen oder Play für automatische Animation.
Interaktive Visualisierung
Simuliert Exception-Handling mit try, catch, finally und Exception-Hierarchie.
Faustregel zum Mitnehmen: try → catch (matchender Typ) → finally (immer). Die Reihenfolge der catch-Blöcke matcht von oben nach unten — spezifischer Typ zuerst, allgemeiner Fallback zuletzt.
Klausurfragen mit Lösungen (8)
Antwort: finally läuft IMMER — egal ob Exception oder nicht
Erklärung: finally läuft IMMER: ohne Exception, mit Exception (egal ob abgefangen oder nicht), nach return im try. Genau dafür ist es da: garantiertes Aufräumen (Datei schließen, Verbindung trennen).
Antwort: Checked Exceptions MÜSSEN behandelt werden (catch oder throws), Unchecked nicht
Erklärung: Checked Exceptions (z.B. IOException) zwingen den Compiler dazu, dass der Aufrufer reagiert (catch oder throws). Unchecked sind RuntimeException-Subklassen (NullPointer, Arithmetic) — können behandelt werden, müssen aber nicht. Python kennt diese Unterscheidung nicht.
Antwort: Compile-Fehler — Exception ist Oberklasse, fängt schon alles
Erklärung: catch(Exception) fängt schon alle Subklassen — der zweite catch(ArithmeticException) wäre nie erreichbar. Der Compiler erkennt das und meldet 'Exception ArithmeticException already caught'. Reihenfolge: spezifisch zuerst.
Antwort: Sie wird an den Aufrufer weitergegeben (propagiert), bis irgendwer fängt oder das Programm abbricht
Erklärung: Eine ungefangene Exception propagiert die Aufrufstack hoch. Wenn niemand fängt, bricht das Programm ab und der Stack-Trace wird gedruckt. finally-Blöcke laufen aber trotzdem auf dem Weg nach oben.
Antwort: Um Ressourcen automatisch zu schließen — auch wenn eine Exception fliegt
Erklärung: try-with-resources / with sorgt dafür, dass die Ressource (Datei, Stream, Connection) automatisch geschlossen wird — auch im Fehlerfall. Ersetzt das alte 'finally { resource.close() }'-Boilerplate. Ressource muss AutoCloseable / __exit__ implementieren.
Antwort: NullPointerException
Erklärung: NullPointerException erbt von RuntimeException → unchecked. IOException, SQLException und ClassNotFoundException sind direkte Subklassen von Exception → checked → müssen behandelt werden.
Antwort: Sagt dem Compiler: diese Methode kann diese Exception werfen, Aufrufer muss sie behandeln
Erklärung: throws deklariert: 'diese Methode könnte diese (checked) Exception weiterreichen'. Der Aufrufer muss dann reagieren (catch oder selbst throws). Bei unchecked Exceptions ist throws optional. throw (ohne s) wirft tatsächlich eine Exception.
Antwort: 2
Erklärung: Hinterhältige Klausurfrage! finally läuft IMMER — auch nach return im try. Wenn finally selbst return hat, überschreibt es das try-return. Hier: 2. Best Practice: nie return in finally, sehr verwirrend.
Methoden, Parameter, Rückgabewerte. Code, der wiederverwendbar wird.