J'ai eu "l'opportunité" de récupérer plusieurs projets et les cadres ont remplacé toute l'équipe de développement car l'application avait trop d'erreurs et les utilisateurs étaient fatigués des problèmes et des contournements. Ces bases de code avaient toutes une gestion centralisée des erreurs au niveau de l'application, comme le décrit la réponse la plus votée. Si cette réponse est la meilleure pratique, pourquoi cela n'a-t-il pas fonctionné et a-t-il permis à l'équipe de développement précédente de résoudre les problèmes? Peut-être que parfois cela ne fonctionne pas? Les réponses ci-dessus ne mentionnent pas combien de temps les développeurs passent à résoudre des problèmes uniques. Si le temps de résolution des problèmes est la mesure clé, l'instrumentation du code avec les blocs try..catch est une meilleure pratique.
Comment mon équipe a-t-elle résolu les problèmes sans modifier de manière significative l'interface utilisateur? Simple, chaque méthode a été instrumentée avec try..catch bloqué et tout a été enregistré au point d'échec avec le nom de la méthode, les valeurs des paramètres de méthode concaténées dans une chaîne transmise avec le message d'erreur, le message d'erreur, le nom de l'application, la date, et version. Avec ces informations, les développeurs peuvent exécuter des analyses sur les erreurs pour identifier l'exception qui se produit le plus! Ou l'espace de noms avec le plus grand nombre d'erreurs. Il peut également valider qu'une erreur qui se produit dans un module est correctement gérée et n'est pas causée par plusieurs raisons.
Un autre avantage pro de ceci est que les développeurs peuvent définir un point d'arrêt dans la méthode de journalisation des erreurs et avec un point d'arrêt et un simple clic sur le bouton de débogage "step out", ils sont dans la méthode qui a échoué avec un accès complet au réel objets au point de défaillance, facilement accessibles dans la fenêtre immédiate. Il facilite le débogage et permet de faire glisser l'exécution vers le début de la méthode pour dupliquer le problème et trouver la ligne exacte. La gestion centralisée des exceptions permet-elle à un développeur de répliquer une exception en 30 secondes? Non.
L'instruction "Une méthode ne doit intercepter une exception que lorsqu'elle peut la gérer de manière raisonnable." Cela implique que les développeurs peuvent prévoir ou rencontreront toutes les erreurs pouvant survenir avant la publication. Si cela était vrai à un niveau supérieur, le gestionnaire d'exceptions d'application ne serait pas nécessaire et il n'y aurait pas de marché pour Elastic Search et logstash.
Cette approche permet également aux développeurs de trouver et de résoudre les problèmes intermittents en production! Souhaitez-vous déboguer sans débogueur en production? Ou préférez-vous prendre des appels et recevoir des courriels d'utilisateurs en colère? Cela vous permet de résoudre les problèmes avant que quiconque ne le sache et sans avoir à envoyer un courrier électronique, une messagerie instantanée ou Slack avec le support, car tout le nécessaire pour résoudre le problème est là. 95% des numéros n'ont jamais besoin d'être reproduits.
Pour fonctionner correctement, il doit être combiné avec une journalisation centralisée qui peut capturer l'espace de nom / module, le nom de classe, la méthode, les entrées et le message d'erreur et le stocker dans une base de données afin qu'il puisse être agrégé pour mettre en évidence la méthode qui échoue le plus afin qu'elle puisse être fixe en premier.
Parfois, les développeurs choisissent de lever des exceptions dans la pile à partir d'un bloc catch, mais cette approche est 100 fois plus lente que le code normal qui ne lève pas. La capture et la libération avec journalisation sont préférées.
Cette technique a été utilisée pour stabiliser rapidement une application qui échouait toutes les heures pour la plupart des utilisateurs d'une entreprise Fortune 500 développée par 12 développeurs sur 2 ans. À l'aide de ces 3000 exceptions différentes ont été identifiées, corrigées, testées et déployées en 4 mois. Cela correspond en moyenne à un correctif toutes les 15 minutes en moyenne pendant 4 mois.
Je suis d'accord que ce n'est pas amusant de taper tout ce qui est nécessaire pour instrumenter le code et je préfère ne pas regarder le code répétitif, mais ajouter 4 lignes de code à chaque méthode en vaut la peine à long terme.