Discussion :

[giova_fr]

Bonjour à tous.
Je suis l'auteur d'un logiciel qui est désormais plutot imposant en nombre de lignes de code.

Voila mon "problème", il arrive que des exceptions de bases soient levées, je pense à KeyNotFoundException et NullReferenceException principalement.

Le problème c'est que ces exceptions ne me disent pas grand chose. J'aimerai connaitre le nom de la variable qui est null, on encore le nom de la collection et de la clé qui pose problème.

Quels astuces pourriez vous me donner à ce sujet?

Merci d'avance pour votre aide.

[GuruuMeditation]

Si tu vas dans l'ecran Exceptions de VS (crtl + E, D) tu peux checker la ligne "Common Language Runtime Exceptions". Quand il y aura une exception, le débugger va se mettre sur la ligne exacte qui renvoie une exception. C'est souvent plus clair comme ça.

[infdunord]

Bonjour,

je te conseille d'utiliser le callStack c'est tres pratique pour retrouver la ligne qui a causer l'exception ou aussi click sur Debug/Exceptions et coche CLR

[Bluedeep]

Quels astuces pourriez vous me donner à ce sujet?

Merci d'avance pour votre aide.

Déja en laissant les fichiers pdb en place, tu peux récupérer le numéro de ligne où a été levée l'exception dans le StackTrace.

Par ailleurs, jamais on utilise uniquement le type de l'exception, c'est une information tout à fait insuffisante.

Dans l'exception, tu utilises :

- le type
- le message
- la stack trace (qui va contenir en plus le numéro de ligne si pdb présents).
- l'inner exception => que tu analyses de la même manière que l'exception et de manière récursive car une "inner" peut avoir elle même une "inner", etc ....

Après les autres infos dépendent du type d'exception.

Je suis néanmoins un peu surpris que ayant un logiciel "...plutot imposant en nombre de lignes de code" (sic) tu n'ais pas de sérialisation d'exception complète dans tes logs.

[giova_fr]

Merci pour vos réponses, malheureusement elles ne m'aide pas, explication :

Cela se passe chez mes clients, or :
1) je ne leur donne pas les pbo
2) les pbo ne serviraient à rien car le programme est obstrué donc impossible à lier avec un pbo.

Pour chopper les infos de l'exception, je fais toujours une boucle du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
String msg = String.Empty;
Exception curErr = error;
do
{
msg +=String.Format("\r\n-----\r\n{0}",curErr.ToString());
curErr = curErr.InnerException;
 
}while( curErr != null);

Exception.ToString() contient à la fois le type, le message, la stack.

En fait je me demandais si il n'y avais pas une solution, peut etre en utilisant de la reflexion, pour obtenir plus d'infos d'une exception, par exemple récupérer la valeur des arguments de chaque methode dans la stack, ca serait super !

[meziantou]

En fait je me demandais si il n'y avais pas une solution, peut etre en utilisant de la reflexion, pour obtenir plus d'infos d'une exception, par exemple récupérer la valeur des arguments de chaque methode dans la stack, ca serait super !

Pas possible avec la reflexion

[Invité]

Voila mon "problème", il arrive que des exceptions de bases soient levées, je pense à KeyNotFoundException et NullReferenceException principalement.

Dans ce cas désolé de te le dire mais je pense que tu n'as pas proprement codé ton logiciel. Surtout pour l'exception KeyNotFoundException qui est typiquement liée à l'accès à un dictionnaire alors que la clef que tu lui fournis n'existe pas. Pour le NullReferenceException c'est discutable.

Quels astuces pourriez vous me donner à ce sujet?

KeyNotFoundException : vérifier que la clef utiliséé existe bien dans le dictionnaire avant d'essayer d'avoir la valeur associée.

NullReferenceException : tu codes ton logiciel donc tu crées des classes, fonctions etc. Il est recommandé que pour les fonctions recevant des paramètres type référence de toujours vérifier dès la première ligne de la fonction que les paramètres obligatoires sont renseignés donc différents de null. Si c'est null alors tu balances l'exception ArgumentNullException qui là pour ça exactement. Si tu déclenches cette exception alors dans la StackTrace du code appelant tu auras le nom du paramètre et aussi le nom de la fonction concernée.

[giova_fr]

Je ne peux que te donner raison là dessus.

En fait, cela fait 2 ans que mon logiciel évolu, je me retrouve donc avec des dicos ou autres trimbalés de methodes en methodes. Celles en haut de la pile font les vérifs comme tu l'as souligné.

Puis un beau jour on intercalle une methode au milieu de tout ça. On se dit, "c'est bon, ma variable elle a été vérifiée N fois par les autres methodes en amont "

Et oui je sais faudrait faire du TDD, mais c'est toujours là même chose, on a pas le temps de trop en faire sinon on n'avance plus.

Bref j'ai 10000 lignes de code et des fois quelques impasses, assez lourd à débugger vu le manque d'infos. En même temps si je faisais tout parfaitement comme il faut je n'aurai pas fais le 1/3 du boulot

Alors j'esperai un petit miracle à mettre dans mon catch du dernier espoire (celui qui envoit un rapport d'erreur au serveur).

[Bluedeep]

Alors j'esperai un petit miracle à mettre dans mon catch du dernier espoire (celui qui envoit un rapport d'erreur au serveur).

Faut voir du coté des framework d'instrumentation, mais ça fait pas des miracles non plus (par exemple, ca ne fait pas repousser les cheveux, et je le déplore ).