Antwort.

In Kotlin wird das Exception Handling durch die Konstruktion try/catch/finally realisiert, unterscheidet sich jedoch vom Java-Ansatz, indem es den Schwerpunkt auf Unchecked Exceptions und einen klaren Syntax legt. Ein wichtiges Unterscheidungsmerkmal ist, dass es in Kotlin keine checked exceptions gibt, was den Programmierer von der Notwendigkeit entlastet, throws anzugeben und solche Ausnahmen abzufangen.

Hintergrund der Frage

Java verwendet checked/unchecked exceptions, bei denen checked eine explizite Behandlung oder Deklaration erfordern. Dies führt oft zu übermäßigem Boilerplate-Code und unhandlichem Code. Kotlin ist einfacher konzipiert – alle Ausnahmen sind in der Regel unchecked (von RuntimeException abgeleitet), was die Behandlung erleichtert und den Code lesbarer macht.

Problem

Java-Entwickler versuchen in Kotlin, checked exceptions abzufangen und anzugeben – der Code wird kompiliert, aber der Sinn geht verloren. Darüber hinaus führt die Verwendung von finally ohne Verständnis der Nuancen zu Lecks oder nicht funktionierendem Code.

Lösung

Verwenden wir try/catch/finally in Kotlin prägnant und zielgerichtet:

fun process(data: String): Int = try {
    data.toInt()
} catch (e: NumberFormatException) {
    0
} finally {
    println("Verarbeitung abgeschlossen")
}

try/catch/finally kann ein Ausdruck sein, d.h. einen Wert zurückgeben, der das Endergebnis der Funktion wird oder einer Variablen zugewiesen wird.
Man kann mehrere Ausnahmen abfangen, when-Schalter innerhalb von catch verwenden, um unterschiedlich auf Ausnahmetypen zu reagieren.

Schlüsselfeatures:

Keine checked exceptions – keine Notwendigkeit, sie zu deklarieren oder ausdrücklich zu behandeln.
Die try-Konstruktion kann als Ausdruck funktionieren (gibt ein Ergebnis zurück).
finally kann für abschließende Aktionen verwendet werden (z.B. Ressourcen schließen), aber man sollte keine Operationen ausführen, die den Rückgabewert modifizieren.

Fangfrage.

Was passiert, wenn eine Ausnahme im finally-Block geworfen wird? Wie beeinflusst das den Rückgabewert?

Ausnahmen, die aus finally geworfen werden, überschreiben immer alle anderen Ausnahmen oder Rückgaben aus dem try/catch-Block, was zu einem Verlust wichtiger Daten über die Ursache des Fehlers führen kann.

fun demo(): Int = try { 1 } finally { throw RuntimeException("Fehler in finally") }

Kann try/catch in Kotlin ein Ausdruck sein? Was ist der Unterschied zu Java?

Ja. try/catch/finally in Kotlin sind Ausdrücke, daher können sie ein Ergebnis zurückgeben und an Stellen verwendet werden, an denen Werte gültig sind.

val value = try { risky() } catch (e: Exception) { fallback() }

In Java sind sie nur Anweisungen.

Muss man Ausnahmen in Kotlin abfangen, wenn eine externe Java-Funktion mit throws aufgerufen wird?

Nein. Da checked exceptions vom Kotlin-Compiler ignoriert werden: Man muss sie nicht ausdrücklich abfangen, sie können jedoch während der Ausführung trotzdem geworfen werden.

Typische Fehler und Antipatterns

Übermäßiges Abfangen aller Ausnahmen (catch (e: Exception)) – wir fangen das, was wir nicht korrekt behandeln können.
Falsche Verwendung von finally – Modifizierung des Rückgabewertes oder Weitergeben von Ausnahmen.
Versuche, throws-Deklarationen innerhalb von Kotlin-Code zu verwenden.

Beispiel aus dem Leben

Negativer Fall

Es wird überall catch (e: Exception) eingefügt, ohne zwischen echten und erwarteten Fehlern zu differenzieren. finally wird für die Wertübergabe verwendet, was zu unerwartetem Verhalten bei Fehlern führt.

Vorteile:

Sehr robust gegen beliebige Fehler.

Nachteile:

Schwer zu debuggen
Fehlermeldungen und die Gründe für ihr Auftreten gehen verloren
Echte Probleme werden verborgen.

Positiver Fall

Es wird nur mit dem Abfangen von erwarteten Fehlern gearbeitet, finally nur für das Bereinigen von Ressourcen verwendet, und try/catch wird als Ausdruck verwendet, wo es die Lesbarkeit erhöht.