Lorsque je consigne des erreurs, j'inclue généralement la trace de la pile. C'est bien, mais souvent, il est difficile de dire où est l'erreur.Un journal des erreurs plus complet
Est-il possible de mettre en place une routine qui recueille, peut-être par réflexion, les paramètres, les variables locales, etc ... au moment où l'erreur s'est produite?
Si vous ne disposez pas de VS2010, vous pouvez utiliser PostSharp pour intégrer du code afin de collecter des paramètres lorsque des fonctions sont appelées. Il va ralentir le code, donc c'est seulement utile pour le débogage.
EDIT: (la promotion de ce à partir d'un commentaire que je viens de faire)
Si vous voulez utiliser dans la production, vous pouvez limiter la portée du tissage PostSharp, il ne fonctionne que sur certaines classes/namespaces/assemblées (ou même des fonctions), ou vous pouvez limiter ce que vous faites lorsque votre conseil est exécuté. Une chose que j'ai essayée, mais que je n'ai pas complètement suivie, était que les méthodes de conseil enregistraient simplement les informations de trame de pile dans un tampon circulaire. Lorsqu'une exception se produit, votre enregistreur peut récupérer les informations de la pile à partir du tampon circulaire et générer un message de journal approprié. Sinon, les informations de trame sont simplement écrasées lorsque le tampon circulaire se remplit. Vous pouvez même simplement utiliser une pile au lieu d'un tampon circulaire et faire en sorte que cette pile croisse et se rétrécisse, en enregistrant les informations sur l'image, à mesure que la pile d'appels s'agrandit et se rétracte. Avertissement: vous ne serez pas en mesure d'obtenir des informations sur le cadre à partir d'un code d'infrastructure ou d'un code tiers qui ne peut pas être modifié par PostSharp.
PostSharp est un bon moyen d'activer la journalisation Trace à des fins de débogage, mais cela peut certainement générer un _lot_ de bruit si elle n'est pas utilisée avec précaution. J'ai vu des applications en production qui génèrent 100 Mo de fichiers journaux chaque jour. Ce sont des données précieuses que vous avez tant que vous avez de l'espace disque, vous pouvez tolérer le coup de performance et avoir les outils appropriés en place pour analyser/filtrer les journaux afin que vous puissiez leur donner un sens. –
Si vous pouvez effectuer une mise à niveau vers VS2010, vous pouvez essayer d'utiliser la fonctionnalité IntelliTrace, qui fait exactement cela.
Bien que vous pourriez avoir besoin de souscrire une deuxième hypothèque pour payer la licence Ultimate Edition. :) –
Je voulais dire une fois que je déploie l'application en production, pas pendant le développement. – AngryHacker
Tout d'abord, vous ne devriez pas avoir ces problèmes en production. Faites de meilleurs tests et commencez par les tester. Deuxièmement, je ne suis pas sûr, mais il est possible que certains de ces éléments soient disponibles en production. Je serais surpris si les collecteurs de données doivent être lancés à partir de Visual Studio. –
Pouvez-vous donner un exemple de "ne peut pas dire où l'erreur s'est produite"? Je me demande si votre problème est une mauvaise gestion des exceptions (détruisant la trace de la pile des appels), ou si vous avez juste besoin d'aide pour lire les traces de la pile. –
La trace de la pile ne montre malheureusement pas la valeur des variables locales/paramètres. afaik vous ne pouvez pas le faire via la journalisation de l'exécution - uniquement en entrant par effraction dans un débogueur (c'est-à-dire VS). Cependant, il devrait vous dire exactement où l'exception se produit (l'exception extérieure au moins). –
Mauvaise gestion des exceptions est ce que je pensais aussi. J'ai très souvent vu la gestion des exceptions comme 'try {...} catch (Exception ex) {Log.Error (ex); jeter ex; } 'ou même simplement' try {...} catch (Exception ex) {throw ex; } ', les deux jettent la trace de la pile dans l'exception quand' throw ex; 'est exécuté. Si une exception doit être relancée, il est généralement préférable d'utiliser 'throw;' comme dans 'try {...} catch (Exception ex) {Log.Error (ex); jeter; } 'ou pour lancer une nouvelle exception avec l'exception d'origine comme exception interne. –