Comment fonctionne la gestion des exceptions en Kotlin ? Décrivez les nuances, la différence avec Java, le traitement des exceptions checked/unchecked, 'try', 'catch', 'finally', la propagation et les meilleures pratiques. Donnez un exemple.

Réponse.

Kotlin implémente la gestion des exceptions de manière similaire à Java, mais avec des différences importantes. En Kotlin, on utilise les constructions familières try, catch et finally, mais la différence fondamentale est que Kotlin n'a pas d'exceptions checked. Cela signifie que toutes les exceptions (erreurs d'exécution) sont considérées comme unchecked — il n'est pas nécessaire de les déclarer dans la signature de la fonction et de les intercepter explicitement.

Points principaux :

• Les blocs try/catch/finally permettent d'intercepter et de gérer les exceptions. Le bloc finally s'exécute toujours, même si une exception est levée.
• Différence avec Java : en Kotlin, toutes les exceptions sont unchecked. Cela simplifie la syntaxe, mais nécessite une approche attentive du traitement des erreurs.
• Kotlin prend en charge "return value" dans le bloc try, c'est-à-dire que try peut être utilisé comme une expression, renvoyant un résultat.
• Nouvelles idiomes : il est recommandé d'éviter d'utiliser try/catch pour le contrôle de flux — utilisez-les uniquement pour des situations vraiment exceptionnelles.

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

Meilleures pratiques :

• Ne pas utiliser pour gérer la logique (contrôle de flux).
• Utilisez "gestion des ressources" avec use pour la fermeture automatique (par exemple, fichiers).
• Ne masquez pas les exceptions avec un catch vide.

Question piège.

En Kotlin, faut-il indiquer dans la signature de la fonction quelles exceptions elle peut lever (comme en Java — via throws) ?

Réponse correcte : Non, en Kotlin, il n'y a pas de mécanisme pour les exceptions checked. Toutes les exceptions sont unchecked. Il n'existe pas de syntaxe throws dans la signature de la fonction (L'exception est l'annotation @Throws pour la compatibilité avec Java, uniquement pour l'interopérabilité).

Exemples d'erreurs réelles dues à un manque de connaissance des subtilités du sujet.

---

Histoire

Dans un projet, nous avons migré un code Java utilisant des exceptions checked (par exemple, IOException). Après la migration vers Kotlin, le développeur a oublié de gérer l'exception lors de la manipulation de fichiers — l'application a commencé à planter sur des fichiers réels, car personne ne gérait les erreurs IO, pensant que le compilateur avertirait, comme en Java.

---

Histoire

Un membre de l'équipe a erronément utilisé try/catch pour le contrôle de flux et a ralenti l'analyse des logs (il a attrapé NumberFormatException pour chaque ligne invalide — les performances ont chuté de manière significative avec un grand volume de données).

---

Histoire

Dans un projet pour la JVM via Kotlin, du code Java a été appelé, qui déclarait des exceptions checked (throws). Le code Kotlin ne gérait pas les exceptions, pensant que "tout est unchecked" — en conséquence, une erreur critique est passée inaperçue jusqu'à un incident en production.