Perché è meglio gestire gli errori nei blocchi `catch` invece di lasciarli vuoti

Regola
Gestire errori in catch . 
Blocco catch blocchi assorbono silenziosamente ignorano gli errori, 
rendendo il debug difficile. 
Linguaggi supportati: Java, C, C++, PHP, JavaScript, 
TypeScript, Go, Python

Introduzione

I blocchi di intercettazione vuoti sono uno degli anti-pattern più pericolosi nel codice di produzione. Quando le eccezioni vengono intercettate ma non gestite, l’errore scompare senza lasciare traccia. L’applicazione continua a funzionare con uno stato corrotto, dati non validi o operazioni fallite che avrebbero dovuto interrompere l’esecuzione. Gli utenti riscontrano errori silenziosi in cui le funzionalità non funzionano, ma non ricevono alcun messaggio di errore. I team operativi non dispongono di log su cui basare il debug. L’unico indizio che qualcosa non va arriva ore o giorni dopo, quando i guasti a cascata rendono il sistema inutilizzabile.

Perché è importante

Debug e risposta agli incidenti: i blocchi `catch` vuoti eliminano i log degli errori. Gli ingegneri non dispongono di trace dello stack, messaggi di errore o indicazioni su quando o dove si sia verificato il guasto, rendendo quasi impossibile riprodurre i problemi.

Corruzione silenziosa dei dati: quando le operazioni sul database o le chiamate alle API falliscono all’interno di blocchi catch vuoti, l’applicazione prosegue come se avessero avuto esito positivo. I record vengono aggiornati solo parzialmente, le transazioni rimangono incomplete e, quando la corruzione viene individuata, la traccia di audit è ormai andata perduta.

Vulnerabilità di sicurezza: i blocchi catch vuoti nascondono problemi di sicurezza quali errori di autenticazione o controlli di autorizzazione. Un malintenzionato che provochi un'eccezione in un percorso critico per la sicurezza potrebbe aggirare completamente le protezioni se l'errore venisse ignorato senza alcun avviso.

Errori a cascata: quando gli errori vengono ignorati, l'applicazione continua a funzionare in uno stato non valido. Anche le operazioni successive, che dipendono dal risultato dell'operazione fallita, falliranno a loro volta, creando una catena di errori che distoglie i tecnici dalla vera causa principale.

Esempi di codice

❌ Non conforme:

async function updateUserProfile(userId, profileData) {
    try {
        await db.users.update(userId, profileData);
        await cache.invalidate(`user:${userId}`);
        await searchIndex.update(userId, profileData);
    } catch (error) {
        // TODO: handle error
    }

    return { success: true };
}

Perché è sbagliato: se un'operazione fallisce, l'errore viene ignorato senza alcun avviso e la funzione restituisce un esito positivo. Il database potrebbe essere aggiornato, ma l'invalidazione della cache potrebbe non andare a buon fine, lasciando dati non aggiornati. Oppure l'aggiornamento dell'indice di ricerca potrebbe fallire, rendendo l'utente non ricercabile, senza che alcun log o avviso indichi il problema.

✅ Conforme:

async function updateUserProfile(userId, profileData) {
    try {
        await db.users.update(userId, profileData);
        await cache.invalidate(`user:${userId}`);
        await searchIndex.update(userId, profileData);
        return { success: true };
    } catch (error) {
        logger.error('Failed to update user profile', {
            userId,
            error: error.message,
            stack: error.stack
        });
        throw new ProfileUpdateError(
            'Unable to update profile',
            { cause: error }
        );
    }
}

Perché è importante: ogni errore viene registrato insieme al contesto, fornendo informazioni utili per il debug. L'errore viene propagato al chiamante, consentendo una corretta gestione dell'errore al livello appropriato. I sistemi di monitoraggio possono segnalare questi errori e l'applicazione si arresta rapidamente anziché continuare a funzionare in uno stato non valido.

Conclusione

I blocchi di intercettazione vuoti non sono mai accettabili nel codice di produzione. Ogni eccezione intercettata deve essere quantomeno registrata nei log, e nella maggior parte dei casi deve essere propagata ai chiamanti o attivare specifiche azioni di ripristino. Se è davvero necessario ignorare un errore, documentarne il motivo con un commento che ne spieghi la giustificazione aziendale. L'impostazione predefinita dovrebbe sempre essere quella di gestire gli errori in modo esplicito, non di ignorarli silenziosamente.