Antwoord.

In Kotlin wordt exception handling gerealiseerd met de try/catch/finally constructie, maar het verschilt van de Java-aanpak door de focus op Unchecked Exceptions en de elegantere syntaxis. Een belangrijk onderscheid is dat Kotlin geen checked exceptions heeft, wat de programmeur ontlast van de noodzaak om throws op te geven en dergelijke exceptions te vangen.

Geschiedenis van de vraag

Java gebruikt checked/unchecked exceptions, waarbij checked expliciet moeten worden opgevangen of gedeclareerd. Dit leidt vaak tot overbodige boilerplatecode en onhandige code. Kotlin is eenvoudiger ontworpen: alle exceptions zijn over het algemeen unchecked (overgeërfd van RuntimeException), wat de verwerking vergemakkelijkt en de code leesbaarder maakt.

Probleem

Java-ontwikkelaars proberen in Kotlin checked exceptions op te vangen en aan te geven — de code compileert, maar de betekenis gaat verloren. Bovendien leidt het gebruik van finally zonder bewustzijn van nuances tot lekkages of niet-werkende code.

Oplossing

Gebruik try/catch/finally in Kotlin kort en krachtig:

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

try/catch/finally kan een expressie zijn, dat wil zeggen dit retourneert een waarde die het resultaat van de functie wordt of aan een variabele wordt toegewezen.
Meerdere exceptions kunnen worden opgevangen, en when-switch kan in catch worden gebruikt voor verschillende reacties op verschillende types exceptions.

Belangrijke kenmerken:

Geen checked exceptions — geen noodzaak om te declareren of expliciet op te vangen.
De try-constructie kan als een expressie werken (geeft resultaat terug).
Finally kan voor afsluitende acties worden gebruikt (bijvoorbeeld het sluiten van resources), maar vermijd het uitvoeren van operaties die de returnwaarde wijzigen.

Vragen met een valstrik.

Wat gebeurt er als er een exception wordt gegooid in de finally-blok? Hoe beïnvloedt dit de returnwaarde?

Exceptions die uit finally worden gegooid, overschrijven altijd andere exceptions of returns uit de try/catch-blok, wat kan leiden tot het verlies van belangrijke gegevens over de oorzaak van de crash.

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

Kan try/catch een expressie zijn in Kotlin? Wat is het verschil met Java?

Ja. try/catch/finally in Kotlin zijn expressies, dus ze kunnen een resultaat retourneren en gebruikt worden op plaatsen waar waarden zijn toegestaan.

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

In Java zijn dit alleen operators.

Is het verplicht om exceptions te vangen in Kotlin als er een externe Java-functie met throws wordt aangeroepen?

Nee. Aangezien checked exceptions door de Kotlin-compiler worden genegeerd: ze hoeven niet expliciet te worden gevangen, maar kunnen nog steeds tijdens uitvoering worden gegooid.

Typische fouten en anti-patterns

Onnodig vangen van alle exceptions (catch (e: Exception)) — vangen wat we niet correct kunnen verwerken.
Onjuist gebruik van finally — wijziging van de returnwaarde of het doorgeven van exceptions.
Pogingen om throws-declaraties binnen Kotlin-code te gebruiken.

Voorbeeld uit het leven

Negatief geval

Plaatsen catch (e: Exception) overal zonder onderscheid te maken tussen echte en verwachte fouten. Gebruik finally voor het retourneren van waarden, wat leidt tot onverwacht gedrag bij fouten.

Voordelen:

Zeer resilient tegen elke soort falen.

Nadelen:

Moeilijk te debuggen.
Foutenberichten en hun oorzaken gaan verloren.
Echte problemen worden verborgen.

Positief geval

Vangen alleen verwachte fouten, finally alleen voor het opruimen van resources, en gebruiken try/catch als expressies waar dit de leesbaarheid verhoogt.