Règle
Gestion des erreurs dans catch . 
Les blocs catch vides silencieusement avaler erreurs, 
rendant débogage difficile. 
Langues prises en charge : Java, C, C++, PHP, JavaScript, 
TypeScript, Go, Python

Introduction

Les blocs `catch` vides sont l'un des anti-patterns les plus dangereux dans le code de production. Lorsque des exceptions sont capturées mais non gérées, l'erreur disparaît sans laisser de trace. L'application continue de fonctionner avec un état corrompu, des données invalides ou des opérations échouées qui auraient dû arrêter l'exécution. Les utilisateurs constatent des échecs silencieux où les fonctionnalités ne fonctionnent pas, mais ne reçoivent aucun message d'erreur. Les équipes d'exploitation n'ont pas de journaux pour le débogage. La seule indication qu'un problème existe n'apparaît que des heures ou des jours plus tard, lorsque des défaillances en cascade rendent le système inutilisable.

Pourquoi c'est important

Débogage et réponse aux incidents : Les blocs catch vides éliminent les journaux d'erreurs. Les ingénieurs n'ont aucune trace de pile, message d'erreur ou indication du moment ou de l'endroit où la défaillance s'est produite, ce qui rend les problèmes presque impossibles à reproduire.

Corruption silencieuse des données : Lorsque les opérations de base de données ou les appels d'API échouent à l'intérieur de blocs `catch` vides, l'application continue comme si elles avaient réussi. Les enregistrements sont partiellement mis à jour, les transactions sont incomplètes, et au moment où la corruption est découverte, la piste d'audit a disparu.

Vulnérabilités de sécurité : Les blocs catch vides masquent les échecs de sécurité tels que les erreurs d'authentification ou les vérifications d'autorisation. Un attaquant déclenchant une exception dans un chemin critique pour la sécurité pourrait contourner entièrement les protections si l'erreur est silencieusement ignorée.

Défaillances en cascade : Lorsque les erreurs sont ignorées, l'application continue dans un état invalide. Les opérations ultérieures dépendant du résultat de l'opération échouée échoueront également, créant une chaîne de défaillances qui éloigne les ingénieurs de la cause première réelle.

Exemples de code

❌ 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 };
}

Pourquoi c'est incorrect : Si une opération échoue, l'erreur est silencieusement ignorée et la fonction renvoie un succès. La base de données pourrait être mise à jour mais l'invalidation du cache pourrait échouer, laissant des données obsolètes. Ou la mise à jour de l'index de recherche échoue, rendant l'utilisateur introuvable, sans aucun log ou alerte pour indiquer le problème.

✅ 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 }
        );
    }
}

Pourquoi c'est important : Chaque erreur est journalisée avec son contexte, fournissant des informations de débogage. L'erreur se propage à l'appelant, permettant une gestion appropriée des erreurs au niveau adéquat. Les systèmes de surveillance peuvent alerter sur ces erreurs, et l'application échoue rapidement plutôt que de continuer avec un état invalide.

Conclusion

Les blocs `catch` vides ne sont jamais acceptables dans le code de production. Chaque exception capturée doit au minimum être journalisée, et la plupart doivent être propagées aux appelants ou déclencher des actions de récupération spécifiques. Si vous devez réellement ignorer une erreur, documentez la raison avec un commentaire expliquant la justification métier. Le comportement par défaut doit toujours être de gérer les erreurs explicitement, et non de les ignorer silencieusement.