Gestione degli errori nello sviluppo mobile: cos'è, quali tecniche e come organizzarla

Gestione degli errori in iOS: Do-Catch, Throw, Guard Let

La gestione degli errori in Swift si basa su quattro meccanismi chiave: do-catch, throws, guard let e if-let. A differenza di molti linguaggi, Swift non consente eccezioni non catturate — ogni errore deve essere esplicitamente gestito o dichiarato tramite throws. La gestione degli errori è una competenza critica per lo sviluppo mobile, che influisce direttamente sulla stabilità dell'applicazione.

Do-Catch e Throw

do-catch è il blocco standard per chiamare funzioni contrassegnate con throws. All'interno di do, una funzione viene chiamata con try e, se solleva un errore, il controllo passa a catch. Diversi tipi di errore possono essere gestiti tramite pattern matching. Se un errore non viene gestito, si propaga verso l'alto nello stack (Error Propagation). Per una gestione efficace degli errori in iOS, usa do-catch come meccanismo principale.

Throw viene dichiarato nella firma della funzione: func fetchData() throws -> Data. Ciò significa che il codice chiamante deve gestire l'errore tramite try, try? o try!. try? converte l'errore in nil, try! causa un crash in caso di errore (usalo solo se sei certo del successo). La gestione degli errori tramite throw è una pratica obbligatoria in Swift.

Optional/Nullable e Guard Let

Guard let è una costruzione per l'uscita anticipata da una funzione se il valore è nil. A differenza di if-let, guard let richiede un'uscita (return, throw, break) nel ramo else. Ciò rende il codice più piatto e leggibile — senza blocchi if annidati. Se un optional non può essere nil — usa force unwrap (!), solo quando sei assolutamente certo. In un'app mobile, guard let aiuta a evitare crash durante la gestione dei valori opzionali.

Optional Chaining (user?.address?.city) e nil-coalescing (??) sono zucchero sintattico per lavorare con gli optional senza spacchettare. In IT Sectr, usiamo guard let per validare i parametri di input dell'API e imponiamo al team di evitare force unwrap senza un commento esplicito. Un gestore di errori a ogni livello protegge da guasti imprevisti.

Gestione degli errori in Android: Try-Catch, Elvis, Sealed Class

Kotlin è il linguaggio principale per lo sviluppo Android. Eredita try-catch da Java ma aggiunge alternative più sicure: l'operatore elvis, require, check e sealed class. La gestione degli errori in Kotlin si basa su una combinazione di questi meccanismi. A differenza di Swift, Kotlin non richiede la gestione delle eccezioni verificate (tutte le eccezioni sono unchecked). Per la gestione degli errori nelle applicazioni mobili su Android, usa sealed class come modello principale.

Try-Catch e Operatore Elvis

Try-catch in Kotlin funziona come un'espressione — restituisce un valore. val result = try { fetchData() } catch (e: Exception) { fallbackValue }. Ciò riduce il codice. L'operatore Elvis (?:) è un analogo di nil-coalescing per i tipi nullable: val name = user?.name ?: "Guest". Per la gestione degli errori nelle applicazioni mobili, try-catch come espressione è l'approccio più conciso.

Sealed class è uno strumento potente per modellare gli stati di successo ed errore. sealed class NetworkResult { data class Success(val data: T) : NetworkResult(); data class Error(val message: String) : NetworkResult() }. Se utilizzata in un'espressione when, il compilatore verifica la completezza dei rami. La gestione degli errori tramite sealed class garantisce che nessuno stato rimanga non gestito.

// Sealed class + try-catch — pattern tipico per Android
sealed class NetworkResult<out T> {
    data class Success<out T>(val data: T) : NetworkResult<T>()
    data class Error(val message: String) : NetworkResult<Nothing>()
}

fun fetchUser(id: String): NetworkResult<User> {
    return try {
        NetworkResult.Success(api.getUser(id))
    } catch (e: Exception) {
        NetworkResult.Error("Failed: ${e.message}")
    }
}

Nell'esempio, la sealed class NetworkResult modella due stati: successo con dati ed errore con messaggio. La funzione fetchUser restituisce un risultato in ogni caso e il codice chiamante gestisce entrambi i rami tramite when. Ciò elimina la possibilità di un errore non gestito. La gestione degli errori tramite sealed class è lo standard per lo sviluppo Android in IT Sectr.

Gestione degli errori in Kotlin: Result ed Either

Result è un tipo integrato di Kotlin per rappresentare il risultato di un'operazione che può fallire. Impone la gestione del successo e del fallimento tramite fold, getOrThrow o map. Result è utile nelle catene asincrone (coroutine). La gestione degli errori con Result è uno standard per lo sviluppo mobile in Kotlin.

Result vs Either

Either è un tipo funzionale della libreria Arrow che consente di restituire un valore di uno dei due tipi (Left — errore, Right — successo). A differenza di Result, Either può contenere qualsiasi tipo di errore definito dall'utente. Per progetti semplici, il Result integrato è sufficiente; per progetti complessi, usa Either di Arrow. La scelta dello strumento di gestione degli errori dipende dalla complessità del progetto.

Propagazione degli errori

La propagazione degli errori è un meccanismo in cui un errore si propaga verso l'alto nello stack di chiamata finché non viene gestito. In Kotlin, ciò avviene per impostazione predefinita (eccezioni unchecked). In Swift, si applica solo alle funzioni contrassegnate con throws. Con Result ed Either, gli errori non si propagano — rimangono nel tipo e devi gestirli. Ciò rende la gestione degli errori nelle applicazioni mobili più sicura.

La tabella mostra le differenze chiave. iOS richiede una dichiarazione esplicita degli errori (throws), rendendo il codice più sicuro ma più verboso. Android si basa sulla disciplina dello sviluppatore. In IT Sectr, usiamo sealed class per Android e throws per iOS — questa è la best practice di entrambe le piattaforme per la gestione degli errori nelle applicazioni mobili.

Crash Reporting: Crashlytics e Sentry

Il crash reporting è un sistema di raccolta e analisi dei crash dell'applicazione. Il crash reporting è una parte essenziale della gestione degli errori in produzione. Senza di esso, vieni a conoscenza dei problemi dagli utenti, il che è inaccettabile per la produzione. Due strumenti principali: Firebase Crashlytics (gratuito) e Sentry (gratuito per l'uso di base). Per la gestione degli errori nelle applicazioni mobili, implementa sempre il crash reporting dal primo rilascio.

Firebase Crashlytics

Crashlytics fa parte di Firebase. Raccoglie automaticamente i crash, li raggruppa per stack di chiamata e mostra il numero di utenti interessati. Supporta la registrazione di errori non fatali tramite recordException(). Integrazione: aggiungi l'SDK a build.gradle (Android) o Podfile (iOS). Crashlytics è il miglior strumento gratuito per la gestione degli errori all'avvio di un progetto.

Sentry

Sentry è un sistema multipiattaforma di monitoraggio degli errori. A differenza di Crashlytics, Sentry fornisce tracciamento dettagliato (breadcrumbs), monitoraggio delle prestazioni e supporto per React Native. Consente di visualizzare lo stato dell'applicazione al momento dell'errore. IT Sectr consiglia Sentry per i progetti che necessitano di un controllo completo sulla gestione degli errori nello sviluppo mobile.

Error Boundary in React Native

Error Boundary è un componente React che cattura gli errori JavaScript nell'albero dei componenti figli e mostra un'interfaccia di fallback, prevenendo il crash completo dell'applicazione. Error Boundary è un componente chiave per la gestione degli errori in React Native. Usa error boundaries per schermate critiche e navigazione. La gestione degli errori nelle applicazioni mobili su React Native richiede una configurazione adeguata di Error Boundary al livello superiore.

Implementazione di Error Boundary

Error Boundary viene creato tramite componentDidCatch(error, errorInfo) o static getDerivedStateFromError(error). Non cattura errori nel codice asincrono (setTimeout, requestAnimationFrame), rendering lato server o errori nativi (Native Modules). Per la registrazione, usa l'SDK di crash reporting all'interno di componentDidCatch. Error Boundary è un gestore di errori semplice ma efficace per il livello dell'interfaccia utente.

Errori fatali vs non fatali

Errore fatale è un'eccezione non gestita che causa il crash dell'applicazione. Errore non fatale è un'eccezione che hai catturato e gestito, ma che indica un problema nel codice. Gli errori non fatali vengono registrati tramite Crashlytics/Sentry e aiutano a trovare i bug prima che diventino fatali. Sia gli errori fatali che quelli non fatali richiedono una corretta gestione degli errori nello sviluppo mobile.