Как работает exception handling в Kotlin? Опишите нюансы, отличие от Java, обработку checked/unchecked исключений, 'try', 'catch', 'finally', propagation и best practices. Приведите пример.

Risposta.

Kotlin implementa la gestione delle eccezioni (exception handling) in modo simile a Java, ma con importanti differenze. In Kotlin si utilizzano le strutture familiari try, catch e finally, tuttavia la differenza principale è che in Kotlin non esistono checked exceptions. Ciò significa che tutte le eccezioni (errori di runtime) sono considerate unchecked — non è necessario dichiararle nella firma della funzione e gestirle esplicitamente.

Punti principali:

• I blocchi try/catch/finally consentono di catturare e gestire le eccezioni. Il blocco finally viene eseguito sempre, anche se viene sollevata un'eccezione.
• Differenza rispetto a Java: in Kotlin tutte le eccezioni sono unchecked. Ciò semplifica la sintassi, ma richiede un’attenzione particolare alla gestione degli errori.
• Kotlin supporta il "return value" nel blocco try, cioè try può essere utilizzato come espressione, restituendo un risultato.
• Nuove idioms: si raccomanda di evitare l'uso di try/catch per il controllo del flusso — utilizzateli solo per situazioni veramente eccezionali.

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

Best practices:

• Non utilizzarlo per la gestione della logica (flow control).
• Utilizzate "resource management" con use per la chiusura automatica (ad esempio, file).
• Non silenziare le eccezioni con un catch vuoto.

Domanda insidiosa.

In Kotlin è necessario specificare nella firma della funzione quali eccezioni può lanciare (come in Java - tramite throws)?

Risposta corretta: No, in Kotlin non esiste il meccanismo delle checked exceptions. Tutte le eccezioni sono unchecked. Non esiste la sintassi throws nella firma della funzione (l’eccezione è l’annotazione @Throws per compatibilità con Java, solo per interop).

Esempi di errori reali a causa della mancata conoscenza delle sottigliezze della materia.

---

Storia

Nel progetto abbiamo migrato il codice Java che utilizzava checked exceptions (ad esempio, IOException). Dopo la migrazione a Kotlin, lo sviluppatore ha dimenticato di gestire l'eccezione durante la gestione dei file — l'applicazione ha iniziato a crashare su file reali, perché nessuno gestiva gli errori IO, pensando che il compilatore avesse avvertito, come in Java.

---

Storia

Un membro del team ha erroneamente usato try/catch per il controllo del flusso e ha rallentato il parsing dei log (catturava NumberFormatException per ogni stringa non valida — le prestazioni sono crollate con un grande volume di dati).

---

Storia

In un progetto per JVM tramite Kotlin è stato chiamato codice Java, che dichiarava checked exceptions (throws). Il codice Kotlin non ha gestito le eccezioni, pensando che "tutto fosse unchecked" — di conseguenza, un errore critico è passato inosservato fino a un incidente in produzione.