Risposta.

In Kotlin, la gestione delle eccezioni è realizzata tramite la struttura try/catch/finally, ma si distingue dall'approccio Java per l'accento sulle Unchecked Exceptions e una sintassi più concisa. Un'importante differenza è che in Kotlin non ci sono checked exceptions, il che solleva lo sviluppatore dall'onere di dichiarare throws e gestire tali eccezioni.

Storia della questione

Java utilizza checked/unchecked exceptions, dove le checked richiedono un'intercettazione esplicita o una dichiarazione. Questo porta spesso a boilerplate e codice scomodo. Kotlin è stato progettato per essere più semplice — tutte le eccezioni sono generalmente unchecked (ereditarie da RuntimeException), semplificando la gestione e rendendo il codice più leggibile.

Problema

Gli sviluppatori Java che passano a Kotlin cercano di intercettare e specificare checked exceptions — il codice si compila ma il significato si perde. Inoltre, l'uso di finally senza comprendere i dettagli porta a perdite o codice non funzionante.

Soluzione

Utilizziamo try/catch/finally in Kotlin in modo conciso e pertinente:

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

• try/catch/finally può essere un'espressione, ovvero restituire un valore che diventa il risultato finale della funzione o viene assegnato a una variabile.
• Puoi intercettare più eccezioni, utilizzando un'istruzione when all'interno di catch per diverse reazioni ai tipi di eccezioni.

Caratteristiche chiave:

• Nessuna checked exception — non è necessario dichiarare o gestire esplicitamente.
• La struttura try può funzionare come espressione (restituisce un risultato).
• Finalmente puoi utilizzare finally per azioni finali (ad esempio, chiusura delle risorse), ma non dovresti eseguire operazioni che modificano il valore restituito.

Domande ingannevoli.

Cosa succede se un'eccezione viene lanciata nel blocco finally? Come influisce sul valore di ritorno?

Le eccezioni lanciate da finally sovrascrivono sempre altre eccezioni o return dal blocco try/catch, il che può portare alla perdita di informazioni importanti sulla causa del crash.

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

Può try/catch essere un'espressione in Kotlin? Qual è la differenza rispetto a Java?

Sì. try/catch/finally in Kotlin sono espressioni, quindi possono restituire un risultato e essere utilizzate in luoghi dove sono permessi i valori.

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

In Java sono solo operatori.

È obbligatorio intercettare eccezioni in Kotlin se viene chiamata una funzione Java esterna con throws?

No. Poiché le checked exceptions vengono ignorate dal compilatore Kotlin: non è necessario intercettarle esplicitamente, ma possono comunque essere lanciate durante l'esecuzione.

Errori comuni e anti-pattern

• Intercettazione eccessiva di tutte le eccezioni (catch (e: Exception)) — catturiamo ciò che non possiamo elaborare correttamente.
• Uso errato di finally — modifica del valore restituito o rilascio di eccezioni.
• Tentativi di usare dichiarazioni throws all'interno del codice Kotlin.

Esempio della vita reale

Caso negativo

Inseriscono catch (e: Exception) ovunque, senza differenziare tra errori reali e attesi. Usano finally per restituire un valore, il che porta a comportamenti imprevisti in caso di errori.

Pro:

• Codice abbastanza resistente a qualsiasi guasto

Contro:

• Difficile da debug
• I messaggi di errore e le loro cause vanno perduti
• I problemi reali vengono nascosti

Caso positivo

Usano l'intercettazione solo per errori attesi, utilizzano finally solo per la pulizia delle risorse, e usano try/catch come espressioni dove migliora la leggibilità.

Pro:

• Facile da leggere, mantenere e testare
• Elaborazione degli errori trasparente

Contro:

• Richiede disciplina nella progettazione dell'API e nella gestione delle eccezioni