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-modèles les plus dangereux du code de production. Lorsque des exceptions sont capturées mais non traité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 ratées qui auraient dû interrompre l'exécution. Les utilisateurs constatent des échecs silencieux lorsque des fonctionnalités ne fonctionnent pas, mais ne reçoivent aucun message d'erreur. Les équipes opérationnelles n'ont pas de journaux pour déboguer. La seule indication que quelque chose ne va pas vient quelques heures ou quelques 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 de capture vides éliminent les journaux d'erreurs. Les ingénieurs ne disposent d'aucune trace de pile, d'aucun message d'erreur ni d'aucune indication sur le moment ou l'endroit où l'échec s'est produit, ce qui rend les problèmes pratiquement impossibles à reproduire.

Corruption silencieuse des données : Lorsque des opérations de base de données ou des 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, lorsque la corruption est découverte, la piste d'audit a disparu.

Vulnérabilités en matière de sécurité : Les blocs catch vides masquent les défaillances de sécurité telles que les erreurs d'authentification ou les contrôles d'autorisation. Un attaquant qui déclenche une exception dans un chemin critique pour la sécurité peut contourner entièrement les protections si l'erreur est avalée silencieusement.

Défaillances en cascade : Lorsque des erreurs sont avalées, l'application continue dans un état invalide. Les opérations suivantes, qui dépendent du résultat de l'opération ayant échoué, échoueront également, créant ainsi une chaîne de défaillances qui détourne les ingénieurs de la véritable cause première.

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 faux : si une opération échoue, l'erreur est ignorée silencieusement et la fonction renvoie le succès. La base de données peut être mise à jour, mais l'invalidation du cache peut échouer, laissant des données périmées. Ou bien la mise à jour de l'index de recherche échoue, rendant l'utilisateur introuvable, sans qu'aucun journal ou alerte n'indique 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 cela est-il important ? Chaque erreur est enregistrée avec son contexte, ce qui permet d'obtenir des informations de débogage. L'erreur se propage à l'appelant, ce qui permet de gérer les erreurs au niveau approprié. Les systèmes de surveillance peuvent signaler ces erreurs, et l'application échoue rapidement au lieu de continuer avec un état invalide.

Conclusion

Les blocs catch vides ne sont jamais acceptables dans un code de production. Chaque exception capturée doit être journalisée au minimum, et la plupart doivent se propager aux appelants ou déclencher des actions de récupération spécifiques. Si vous avez réellement besoin d'ignorer une erreur, documentez-en la raison avec un commentaire expliquant la justification commerciale. Le défaut devrait toujours être de traiter les erreurs de manière explicite, et non de les ignorer silencieusement.