Hoe werkt exception handling in Kotlin? Beschrijf de nuances, het verschil met Java, de verwerking van checked/unchecked uitzonderingen, 'try', 'catch', 'finally', propagatie en best practices. Geef een voorbeeld.

Antwoord.

Kotlin implementeert exception handling op een vergelijkbare manier als Java, maar met belangrijke verschillen. In Kotlin worden de bekende constructies try, catch en finally gebruikt, maar het fundamentele verschil is dat Kotlin geen checked exceptions kent. Dit betekent dat alle uitzonderingen (runtime-fouten) als unchecked worden beschouwd — ze hoeven niet in de functie-handtekening te worden gedeclareerd en hoeven niet expliciet te worden opgevangen.

Belangrijkste punten:

• try/catch/finally blokken stellen je in staat om uitzonderingen op te vangen en te verwerken. Het finally blok wordt altijd uitgevoerd, zelfs als er een uitzondering is gegooid.
• Verschil met Java: in Kotlin zijn alle uitzonderingen unchecked. Dit vereenvoudigt de syntax, maar vereist een zorgvuldige benadering van error handling.
• Kotlin ondersteunt "return value" in het try blok, d.w.z. try kan worden gebruikt als een expressie die een resultaat retourneert.
• Nieuwe idiomen: het wordt aanbevolen om het gebruik van try/catch voor flow-control te vermijden — gebruik ze alleen voor werkelijk uitzonderlijke situaties.

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

Best practices:

• Niet gebruiken voor logica beheer (flow control).
• Gebruik "resource management" met behulp van use voor automatische sluiting (bijv. bestanden).
• Sluit uitzonderingen niet in met lege catch.

Vraag met een valstrik.

Moet je in Kotlin aangeven in de handtekening van de functie welke uitzonderingen deze gooit (zoals in Java — via throws)?

Correct antwoord: Nee, in Kotlin is er geen mechanisme voor checked exceptions. Alle uitzonderingen zijn unchecked. Er bestaat geen syntax throws in de handtekening van de functie (Uitzondering — annotatie @Throws voor compatibiliteit met Java, alleen voor interop).

Voorbeelden van echte fouten door gebrekkige kennis van de nuances van het onderwerp.

---

Verhaal

In het project migreerden ze Java-code die gebruik maakte van checked exceptions (bijv. IOException). Na de migratie naar Kotlin vergat de ontwikkelaar de uitzondering op te vangen bij het werken met bestanden — de applicatie begon te crashen op echte bestanden, omdat niemand IO-fouten verwerkte, in de veronderstelling dat de compiler zou waarschuwen, zoals in Java.

---

Verhaal

Een van de teamleden gebruikte ten onrechte try/catch voor flow-control en vertraagde de verwerking van logbestanden (v Ongeldig aantal formatteerfouten voor elke ongeldige regel — de prestaties daalden scherp bij een groot aantal gegevens).

---

Verhaal

In een project voor JVM werd er via Kotlin Java-code aangeroepen die checked exceptions (throws) verklaarde. De Kotlin-code verwerkte de uitzonderingen niet, in de veronderstelling dat "alles unchecked" was — als resultaat bleef een kritieke fout onopgemerkt tot een productieve incident.