J'ai un problème avec une solution UGE au travail qui obtient beaucoup de "Référence d'objet non définie sur une instance d'erreurs d'objet". Quelle est la meilleure façon de déterminer l'objet null (s) provoquant l'exception?
Je peux essayer de prendre toutes ces exceptions à un endroit, mais je ne trouve pas un moyen de déterminer le membre qui est null afin que je puisse le réparer correctement. . puisque je peux voir la stacktrace, il serait raisonnable de penser que vous pouvez également obtenir ce qui a provoqué l'erreur.
3 Réponses :
Pensez-y pendant une seconde. C'est une nullreferenceException. Cela signifie que vous essayez d'appeler une méthode ou d'accéder à une propriété sur une référence Alors, qu'est-ce que vous essayez de trouver n'existe effectivement pas.
Normalement pour traquer quelle référence d'objet est NULL un débogueur est utilisé. Il suffit de définir un point d'arrêt sur la ligne provoquant l'exception et d'inspecter toutes les variables pour voir lequel est NULL.
Le débogueur est votre plus grand outil.
A commencé un peu philosophique, mais suivi de bon avis. +1.
Je sais que. Le problème est que c'est une solution déjà en production et je ne peux que recevoir des erreurs par courrier électronique. Je ne peux pas reproduire la plupart des erreurs que certains utilisateurs obtiennent.
@Brunosilva Eh bien, je pense qu'au moins, vous devez voir une trace de pile et une broche pointer sur la ligne avec l'erreur. Pas d'autre moyen à ce sujet.
Ok, pensait qu'il pourrait y avoir un moyen plus facile car je peux obtenir presque toutes les informations de la méthode d'exécution par réflexion.
La réflexion peut faire des choses cooles, mais déterminer ce qui a simplement échoué dans le bloc d'essai n'est pas une bonne utilisation de la réflexion, quelle que soit la possibilité. Modifiez la routine d'envoi de courrier électronique pour envoyer une trace de pile et envisager de pousser les fichiers PDB avec l'application (afin que vous obtenez des numéros de ligne dans ces traces de pile, au lieu des décalages d'octets)
@Brunosilva exactement. Dans de très grands systèmes, il est souvent très difficile de reproduire le problème car il peut être dépendant des données et si les données changent, vous risquez de perdre la possibilité sans une sauvegarde DB bien chronométrée.
@Keiths devrait mettre en place des PDB de toute utilisation, même si le projet est publié sur la libération? Cela vous donnerait-il toujours les numéros de ligne?
La référence null a un nom de symbole. On dirait que cela pourrait être inclus dans la sortie d'exception. "MyDate est null"
Consultez la documentation sur TRY-CATCH http : //msdn.microsoft.com/en-us/library/0yd65esw (v = vs.71) .aspx
Vous pouvez avoir plusieurs captures d'essayer d'essayer de gérer différentes exceptions à leur manière < / p>
Vous ne devriez pratiquement jamais attraper (ou jeter) une exception de référence nulle dans le code de production. Vous devriez rechercher null d'abord dans un bloc si bloque, le cas échéant, pour vous assurer de ne jamais avoir de NRE en premier lieu. Vous ne devriez pas utiliser des exceptions pour le flux de contrôle.
Si vous n'êtes pas capable de déboguer NullReferenceException avec l'IDE au cas où il ne se produit que chez le client ou qu'il est difficile de reproduire, alors NullReferenceException.StactTrace qui possède des informations de fonction / fichier / ligne vous aidera à localiser l'objet NullReferenceException .Tostring () Inclure également StackTrace, par exemple:
système.NullReferenceException: référence d'objet non définie sur une instance d'un objet.
à windowsformsaplication3.form1.button1_click (expéditeur d'objet, Evenargs e) dans D: \ vcs \ windowsformSApplication3 \ windowsformSApplication3 \ form1.cs: ligne 26
Pour activer le numéro de ligne pour la version de version, consultez cet article sur Numéro de lignes d'affichage dans la trace de pile pour l'assemblage .NET en mode de sortie
essai et erreur?
si (thintingwhichcouldbenull == null); sinon si (itotherThingthing == null); sinon si (etc.); ... au moins si vous devez déterminer par programme à déterminer quel objet était null au moment de l'exécution.Pourquoi ne pas simplement laisser le débogueur arrêter sur des exceptions? Ensuite, vous voyez où votre erreur est ...
Je suppose que vous voulez dire la variable ou l'expression qui était
null . Demander l'objet qui étaitnull est absurde.Activez «Pause sur des exceptions de première chance» et déboguer le code. Le code de travail ne doit pas lancer
NullReferenceException s.Si vous avez besoin de cela, vous avez probablement des méthodes trop grandes. Les petites méthodes concises peuvent encore obtenir NRES mais ils sont beaucoup plus faciles à diagnostiquer.
Je ne peux pas déboguer, c'est le code de production. Et je ne peux pas repousser la plupart des bugs.
Si vous ne pouvez pas le déboguer, assurez-vous que les fichiers .PDB correspondants sont copiés de côté des fichiers .dll. Le cadre de pile d'exception contiendra ensuite la ligne de code source. Cela aide à déterminer ce que pourrait NULL.
duplicatural possible de est Un moyen de savoir quel objet a causé l'exception de référence NULL?