Wie funktioniert die Ausnahmebehandlung in Kotlin? Beschreiben Sie Nuancen, Unterschiede zu Java, die Behandlung von checked/unchecked Ausnahmen, 'try', 'catch', 'finally', Propagation und Best Practices. Geben Sie ein Beispiel an.

Antwort.

Kotlin implementiert die Ausnahmebehandlung ähnlich wie Java, jedoch mit wichtigen Unterschieden. In Kotlin werden die bekannten Konstruktionen try, catch und finally verwendet, aber der entscheidende Unterschied ist: In Kotlin gibt es keine checked exceptions. Das bedeutet, dass alle Ausnahmen (Laufzeitanomalien) als unchecked gelten — sie müssen nicht in der Funktionssignatur deklariert und nicht explizit gefangen werden.

Wichtige Punkte:

• try/catch/finally Blöcke ermöglichen das Fangen und Behandeln von Ausnahmen. Der Block finally wird immer ausgeführt, auch wenn eine Ausnahme geworfen wird.
• Unterschied zu Java: In Kotlin sind alle Ausnahmen unchecked. Dies vereinfacht die Syntax, erfordert jedoch eine sorgfältige Vorgehensweise bei der Fehlerbehandlung.
• Kotlin unterstützt „return value“ im try Block, d.h. try kann als Ausdruck verwendet werden, der ein Ergebnis zurückgibt.
• Neue Idiome: Es wird empfohlen, die Verwendung von try/catch zur Flusskontrolle zu vermeiden — verwenden Sie sie nur für wirklich außergewöhnliche Situationen.

fun parseIntOrNull(str: String): Int? = try {
    str.toInt()
} catch (e: NumberFormatException) {
    null
}

Best Practices:

• Nicht zur Steuerung der Logik (flow control) verwenden.
• Verwenden Sie „Ressourcenverwaltung“ mit use für die automatische Schließung (zum Beispiel von Dateien).
• Fangen Sie Ausnahmen nicht mit einem leeren catch ab.

Fangfrage.

Muss man in Kotlin in der Funktionssignatur angeben, welche Ausnahmen sie auslöst (wie in Java — über throws)?

Richtige Antwort: Nein, in Kotlin gibt es keinen Mechanismus für checked exceptions. Alle Ausnahmen sind unchecked. Es gibt keine throws-Syntax in der Funktionssignatur (Die Ausnahme ist die Annotation @Throws für die Kompatibilität mit Java, nur für Interop).

Beispiele für reale Fehler aufgrund mangelnden Wissens über die Feinheiten des Themas.

---

Geschichte

In einem Projekt wurde Java-Code migriert, der checked exceptions verwendete (zum Beispiel IOException). Nach der Migration auf Kotlin vergaß der Entwickler, die Ausnahme bei der Arbeit mit Dateien zu behandeln - die Anwendung begann bei realen Dateien abzubrechen, weil niemand IO-Fehler behandelte, in der Annahme, dass der Compiler wie in Java warnen würde.

---

Geschichte

Ein Teammitglied verwendete fälschlicherweise try/catch zur Flusskontrolle und verlangsamte die Verarbeitung der Protokolle (fing NumberFormatException für jede ungültige Zeile ab - die Leistung fiel bei großen Datenmengen drastisch ab).

---

Geschichte

In einem Projekt für die JVM wurde über Kotlin Java-Code aufgerufen, der checked exceptions (throws) deklarierte. Der Kotlin-Code behandelte die Ausnahmen nicht und ging davon aus, dass "alles unchecked" sei - in der Folge blieb ein kritischer Fehler bis zu einem produktiven Vorfall unbemerkt.