Discussion :

[thierry007]

Bonjour a tous

Je cherches une façon de trouver le nom de la fonction de façon dynamique , pendant l'execution du programme.
Ceci me permet de faire un suivit en cas d'erreur, de savoir ou le problème se situe et d'en avoir un historique dans une DB

Code :

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

1
2
3
4
5
6
7
8
9
10
 Try
 
                  mon code
 
 
           Catch Ex as Exeption
 
                  enregistrement de MaClass/Module et maFonctionEnCours      
 
            End Try

[zoubidaman]

Tu peux l'avoir avec les classes StackTrace et StackFrame. Mais si tu veux faire ça pour toutes tes fonctions, ça risque d'être bien lent.

[Pol63]

dasn un catch ce qui est pratique à enregistrer c'est
- le type d'erreur (ex.gettype.name)
- le message (ex.message)
- voir s'il y a une exception sous jacente (ex.innerexception)
- la pile des appels (ex.Stacktrace)

pour le nom de la classe en cours c'est me.gettype.fullname
le nom de méthodes en cours c'est System.Reflection.MethodInfo.GetCurrentMethod.Name

sinon pour ne pas avoir 50 lignes de code dans les catch, fait une fonction quelque part que tu appelles depuis le catch de manière plus ou moins générique

après y peut y avoir encore pas mal de choses interressantes, mais là déjà ca permet de débugger facilement

sachant que si les fichiers .pdb sont à coté de l'exe, le numéro de ligne sera écrit dans le ex.stacktrace



(et je vois pas ce qu'il y a de lent à faire ca, une levée d'exception n'étant déjà pas très rapide en plus)

[thierry007]

Grand merci pour la réponse qui m'éclaire déjà en grosse partie, je vais faire quelques petits test pour l'ensemble de la gestion catch avec ce que tu m'as donné.

Encore merci

[alex_vino]

C'est très intéressant.

Et comment fait t'on quand on crée une procédure msgErreur() pour connaître le Me.GetType.FullName et System.Reflection.MethodInfo.GetCurrentMethod.Name de l'appellant de la procédure ?

[Pol63]

on ne peut pas vraiment

mais dans ex.Stacktrace on voit bien la méthode d'où vient l'erreur donc la méthode en cours en général on s'en fout
(j'ai précisé comment la trouver car thierry la demandait, mais si on veut limiter le nombre de lignes de code dans les catch c'est pas très pratique)

si on se fait une classe d'enregistrement d'erreur en général on l'appel dans le catch en lui donnant ex et éventuellement me
cette méthode (ex as exception, instance as object) enregistre tout ce qui est intérressant sur ex et quelques truc interréssant sur l'instance (instance.gettype permet de faire de la reflection et de trouver le type, et les valeurs des champs et propriétés)

la valeur des paramètres d'entrées de la méthode (s'il y en a) pourrait etre encore plus pratique, mais la reflection permet seulement de connaitre leurs types
pour les valeurs ca devient du code inbuvable pour la lire dans la pile de la CLR (mais ca reste faisable techniquement)

[alex_vino]

Ok ok merci bien Pol63

[zoubidaman]

(et je vois pas ce qu'il y a de lent à faire ca, une levée d'exception n'étant déjà pas très rapide en plus)

Je disais que ça serait lent s'il utilisait ça dans toutes les fonctions. C'est sûr que s'il ne le fait que dans le catch ça pose tout de suite moins de soucis

[thierry007]

Voila a présent je peux savoir ou j'ai le problème ce qui dans certains cas s'avère très interessant.
Surtout que lorsque le programme est mis dans les mains des utilisateurs, il y a un ta de manipulations aux quelles on ne pense pas toujours et bardaff plantage. Le Catch permet d'en récupérer mais il faut les corigées.

Le but étant de mettre la procédure aux endroits plus critiques et non partout dans le code

Merci encore