J'ai du mal à reproduire quelques erreurs que nous voyons dans notre journal d'erreur.
Cela pourrait être rendu beaucoup plus facile si je savais quel identifiant d'enregistrement une méthode spécifique utilisait lorsqu'il a jeté une exception.
Toutes nos exceptions non gérées sont gérées par notre gestionnaire d'exception globale, qui met tous les détails de l'exception, ainsi que tous les détails de la demande HTTP, dans une table de journaux.
Y a-t-il un moyen de capturer les valeurs de tous les paramètres de la méthode qui a jeté une exception? Ou même mieux, toutes les valeurs jusqu'à la trace de la pile?
3 Réponses :
Je saisirais l'exception dans la méthode de la méthode, rassemblez vos paramètres et toutes les autres informations nécessaires, puis réthrow the Erreur avec une nouvelle applicationException ou une autre exception personnalisée contenant vos informations supplémentaires.
Malheureusement, cela n'est pas possible: à l'époque où vous attrapez l'exception dans le gestionnaire, toutes les cadres de pile avec les paramètres de la méthode sont partis. Une fois que le contrôle quitte votre fonction, vous ne pouvez plus accéder à ses valeurs de paramètre.
Depuis que vous connaissez la fonction spécifique dans laquelle le crash se produit, vous pouvez configurer un gestionnaire d'exception là-bas pour collecter tous les paramètres d'intérêt et rejeter une exception enveloppée. Une fois que le diagnostic est terminé, vous pouvez revenir le code à la normale:
Pas dans mon cas, où une exception est lancée par une bibliothèque tierce partie.
à partir de la documentation Environnement .Stacktrace Je dirais que c'est possible. Ils disent
Les informations de trace de la pile pour chaque appel de méthode sont formatées comme suit:
"à FullClassName. MéthodeName (Méthodeparams) dans le nom de fichier: Line Linenumber"
Dans ce contexte méthodharams sont des noms et des types, non des valeurs, par exemple au système.Linq.Enuméreur.ToDictionary [Tsource, tkey, tonnelement] (i énumérable 1 source, Func 2 Keyselector, Func 2 Émentalector, IequalityComparer 1 comparateur)
Il n'y a aucun moyen de le faire de l'intérieur du CLR, mais certains outils tels que Avicode peuvent le faire en accrochant dans le CLR de l'extérieur, en utilisant essentiellement des crochets de débogage pour obtenir les informations.
Vous pouvez essayer O log4net Logging.apache.org/log4net . Vous pouvez simplement configurer si vous souhaitez voir l'erreur de trace de pile
Vous pouvez configurer procdump (sysinternals) pour capturer une mémoire complète du code géré lorsque des exceptions spécifiques se produisent. Vous pouvez ensuite utiliser pssCor4 (extension de débogage de code géré pour Windbg) pour examiner l'état de processus lorsque l'exception s'est produite - ce produit n'est pas destiné au cœur faible si ...
Vous pourriez également y regarder un autre moyen: pouvez-vous forcer l'exception en exerçant le code présumé? Pour les outils de test Eamle tels que
PEX sont très intelligents lors de la recherche de cas de coin en code.