Réponse.

En Kotlin, la gestion des exceptions est réalisée à l'aide de la structure try/catch/finally, mais elle diffère de l'approche de Java par son accent sur les exceptions non vérifiées (Unchecked Exceptions) et un syntaxe plus concise. Une différence importante est qu'en Kotlin, il n'y a pas d'exceptions vérifiées (checked exceptions), ce qui libère le programmeur de l'obligation de spécifier throws et de capturer de telles exceptions.

Historique de la question

Java utilise des exceptions vérifiées et non vérifiées, où les vérifiées nécessitent une capture explicite ou une déclaration. Cela conduit souvent à un code prolixe et peu pratique. Kotlin a été conçu pour être plus simple : toutes les exceptions sont généralement non vérifiées (héritées de RuntimeException), ce qui facilite la gestion et rend le code plus lisible.

Problème

Les développeurs Java essayant de capturer et de spécifier des exceptions vérifiées en Kotlin — le code se compile, mais le sens est perdu. De plus, l'utilisation de finally sans comprendre les nuances peut provoquer des fuites ou du code non fonctionnel.

Solution

Utilisons try/catch/finally en Kotlin de manière concise et pertinente :

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

• try/catch/finally peut être une expression, c'est-à-dire retourner une valeur qui devient le résultat final de la fonction ou est assignée à une variable.
• On peut capturer plusieurs exceptions, utiliser un switch when à l'intérieur du catch pour réagir différemment selon le type d'exception.

Caractéristiques clés :

• Pas d'exceptions vérifiées — pas besoin de les déclarer ou de les traiter explicitement.
• La structure try peut fonctionner comme une expression (retourne un résultat).
• On peut utiliser finally pour des actions de clôture (par exemple, fermer des ressources), mais il ne faut pas réaliser d'opérations modifiant la valeur de retour.

Questions pièges.

Que se passe-t-il si une exception est levée dans le bloc finally ? Comment cela influence-t-il le retour de la valeur ?

Les exceptions levées depuis finally écrasent toujours toute autre exception ou retour du bloc try/catch, ce qui peut entraîner la perte d'informations importantes sur la cause de l'échec.

fun demo(): Int = try { 1 } finally { throw RuntimeException("erreur dans finally") }

Le try/catch peut-il être une expression en Kotlin ? Quelle est la différence avec Java ?

Oui. try/catch/finally en Kotlin est une expression, donc ils peuvent retourner un résultat et être utilisés dans des contextes où des valeurs sont autorisées.

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

En Java, ce ne sont que des instructions.

Est-il nécessaire de capturer les exceptions en Kotlin si une fonction Java externe est appelée avec throws ?

Non. Étant donné que les exceptions vérifiées sont ignorées par le compilateur Kotlin : il n'est pas nécessaire de les capturer explicitement, mais elles peuvent toujours être lancées pendant l'exécution.

Erreurs courantes et anti-patterns

• Capture non nécessaire de toutes les exceptions (catch (e: Exception)) — nous capturons ce que nous ne pouvons pas traiter correctement.
• Utilisation incorrecte de finally — modification de la valeur de retour ou relance d'exceptions.
• Tentatives de déclaration throws à l'intérieur du code Kotlin.

Exemple de la vie réelle

Cas négatif

Ils insèrent catch (e: Exception) partout, sans différencier les erreurs réelles et attendues. Ils utilisent finally pour retourner une valeur, ce qui conduit à un comportement inattendu en cas d'erreurs.

Avantages :

• Code très résistant à toute défaillance

Inconvénients :

• Difficile à déboguer
• Les messages d'erreur et leurs causes sont perdus
• Les véritables problèmes sont masqués

Cas positif

Ils ne capturent que les erreurs attendues, utilisent finally uniquement pour le nettoyage des ressources, et emploient try/catch comme des expressions là où cela améliore la lisibilité.

Avantages :

• Facile à lire, à maintenir et à tester
• Gestion des erreurs transparente

Inconvénients :

• Nécessite de la discipline dans la conception des API et la gestion des exceptions