Perché dovresti gestire gli errori nei blocchi catch anziché lasciarli vuoti

Regola
Gestisci gli errori nei blocchi catch. 
I blocchi catch vuoti ignorano silenziosamente gli errori, 
rendendo il debugging difficile. 
Linguaggi supportati: Java, C, C++, PHP, JavaScript, 
TypeScript, Go, Python

Introduzione

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

Perché è importante

Debugging e incident response: I blocchi catch vuoti eliminano i log degli errori. Gli ingegneri non hanno a disposizione alcuno stack trace, messaggio di errore o indicazione su quando o dove si sia verificato il guasto, rendendo i problemi quasi impossibili da riprodurre.

Corruzione silenziosa dei dati: Quando le operazioni sul database o le chiamate API falliscono all'interno di blocchi catch vuoti, l'applicazione continua come se avessero avuto successo. I record vengono aggiornati solo parzialmente, le transazioni sono incomplete e, nel momento in cui la corruzione viene scoperta, la traccia di audit è svanita.

Vulnerabilità di sicurezza: I blocchi catch vuoti mascherano problemi di sicurezza come errori di autenticazione o controlli di autorizzazione. Un attaccante che innesca un'eccezione in un percorso critico per la sicurezza potrebbe aggirare completamente le protezioni se l'errore viene ignorato silenziosamente.

Guasti a cascata: Quando gli errori vengono ignorati, l'applicazione continua in uno stato non valido. Le operazioni successive che dipendono dal risultato dell'operazione fallita falliranno a loro volta, creando una catena di guasti che devia l'attenzione degli ingegneri 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é è errato: Se un'operazione qualsiasi fallisce, l'errore viene silenziosamente ignorato e la funzione restituisce un esito positivo. Il database potrebbe essere aggiornato, ma l'invalidazione della cache potrebbe fallire, lasciando dati obsoleti. Oppure l'aggiornamento dell'indice di ricerca fallisce, rendendo l'utente non rintracciabile, senza alcun log o avviso che segnali 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 con il relativo contesto, fornendo informazioni utili per il debugging. L'errore si propaga al chiamante, consentendo una corretta gestione dell'errore al livello appropriato. I sistemi di monitoraggio possono generare avvisi su questi errori e l'applicazione fallisce tempestivamente anziché continuare con uno stato non valido.

Conclusione

I blocchi catch vuoti non sono mai accettabili nel codice in produzione. Ogni eccezione intercettata richiede come minimo la registrazione nei log, e la maggior parte deve propagarsi ai chiamanti o attivare azioni di recupero specifiche. Se è veramente necessario ignorare un errore, documentane il motivo con un commento che spieghi la giustificazione di business. L'approccio predefinito dovrebbe essere sempre quello di gestire gli errori in modo esplicito, senza scartarli silenziosamente.