Version imprimable
Bonjour, je voudrais connaitre le nom de la function dans laquelle je suis...
Je suis dansune classe avec plusieurs public function...et comme Je loggue mes passages dansune console j aimerais connaitre le cheminement..
Comment donc faire pour connaitre le nom de la function dans laquelle je suis.? J ai regardé l objet me. mais il me retourne tout concernant la classe mais rien sur la function...merci
system.reflection.getcurrentmethod
si y a pas de .name
faut faire .gettype. et voir si y a un .name ...
System.Reflection.MethodBase.GetCurrentMethod.NameCitation:
Envoyé par sperot51
Merci
Y a t'il une solution identique qui puisse renvoyer ce meme nom de la function ou il y a eu une erreur ?
J'ai crée un form specifique pour les erreurs qui se charge et s'affiche automatiquement lors d'un bug. J'ai essaye d'implanter System.Reflection.MethodBase.GetCurrentMethod.Name pour avoir en plus cette information, mais bien sur, ca me donne le nom de la methode courante donc celle de la form erreur, et pas la d'ou vient l'erreur.
Y aurait il un moyen de moyenner ? ;)
comment intercepte tu les erreurs ?
car tu peux peut etre appeler getcurrentmethod dans le catch et l'envoyer en parametre à ta gestion d'erreur
sinon il y a moyen d'avoir la pile des appels à tout moment, donc de retrouver la sub d'avant (c'est dans system.diagnostics je crois , stack quelque chose)
dans le pire des cas, à partir d'ex tu peux obtenir beaucoup de chose, dont la méthode du crash, la pile aussi, ex.Stacktrace, la classe, les variables de la classe etc...
Pour cette form d'erreur, j'utilise le on error goto dans un module de gestion.
Pour les trucs plus specifiques j'utilise le Try Catch.
Sinon je vais aller regarder du cote de la pile comme tu me dis.
on error est pas trop bien il me semble
et il y a un addhandler possible sur les erreurs inatrapé (y a eut un post la dessus recemment) qui renvoie ex
genre addhandler erreurnongeree, addresof sub_gestion_erreur
Oui j'ai lu plein de choses negatives sur le on error, mais dans mon cas precis, c'est l'ideal pour intercepter toute erreur non 'prevue'.
J'ai pas encore essaye de la changer en try/catch car ca fonctionne reellement trop bien comme cela :P
Sinon, j'ai pas vu ce post sur ce addhandler, tu aurais pas l'url sous la main ?
non mais fait une recherche sur le forum (ou dans reflector, ou dans msdn) sur UnHandledException
par contre, une question
que fait on error que try catch ne fait pas ?
Bonjour.
Personnellement c'est comme le dit Sperot51 que je fonctionne.
Dans les classes de mon appli, je positionne systématiquement un try/catch qui instancie en cas d'erreur une classe de log avec comme paramétre le nom de la classe en erreur et la criticité.
C'est suivant la criticité que je déclenche ou non l'arrêt de l'application aprés avoir loggé l'erreur et affiché un msg si besoin.
Ca oblige à mettre des try/catch un peu partout mais je n'ai pas trouvé mieux (un gestion de contexte via un class shared me semble pas beaucoup mieux).
Cdt.
Plus qu'à rajouter un rapport de bug automatique avec un retour disant "non corrigé" ou "corrigé dans la version x.x.x", et ça sera magnifique :king:Citation:
Envoyé par olsimare
Il me permet une gestion complete des erreurs.Citation:
Envoyé par sperot51
Dans mes structures d'appli, je lance le soft avec un sub main dans un module, puis un on error en debut pour intercepter toutes les erreurs qui peuvent suivre tout au long de l'execution.
Je place des trycatch que sur des trucs spécifiques qui peuvent etre mieux gere.
L'avance du on error, c'est d'intercepter n'importe ou et n'importe quand.
Le desavantage, c'est un arret quoi qu'il se passe.
Conclusion, comme on peut pas mettre des trycatch à chaque ligne de code, c'est un bon compromis pour intercepter toutes les erreurs (previsibles ou non)
si tu veux dire que on error intercepte les erreurs dans les subs appelées par la sub qui contient le on error
sache que les try catch font pareil ...
en cas d'une erreur dans une sub sans gestion d'erreur, l'erreur est reportée à l'appelant et sa gestion d'erreur s'il y en a une, etc...
par contre le addhandler sur unhandledexception permet de catcher les erreurs qui ne sont pas gérées (ni par on error ni par tryu catch)
Ok pour les subs et sous-subs. (ca je le savais)
Mais intercepte t-il aussi les erreurs des autres forms, dialogs, dlls, etc ...
(la j'ai pas essaye de mettre un try catch à la place du on error ... ca peut aussi peut etre le faire - je l'essayerai quand j'aurais 5 minutes et surtout quand je vais y penser (lol))
Par contre j'ai fais une recherche sur le forum avec ton UnHandledException, mais nada pour retrouver le post que tu me parlais.
C'est une excellente idée de signifier l'etat du bug - merci :king:Citation:
Envoyé par SaumonAgile
Actuellement, quand ya un bug, je verifie si internet=on, puis j'envoi le rapport directement sur mon serveur.
Et si ya internet=off, je place le rapport dans le presse-papier pour c/c pour faciliter l'utilisateur.
Et en affichant bien sur toutes les infos dans ma form speciale erreur.
Difficile de faire plus :yaisse2:
quand j'aurais 2min j'essairais de te rechercher ce truc
moi j'avais pas réussi à le mettre en place mais ca doit etre bien quand meme lol
Ok cool.
Par contre t'es pas trop encourageant :lol:
faut dormir la nuit !
^^
sinon j'ai retrouvé le post :
http://www.developpez.net/forums/sho...d.php?t=404907
dans lequel smyley nous indique http://msdn2.microsoft.com/en-us/lib...exception.aspx
je suis pas sur que c'est ca que j'avais essayé de mettre en place
moi c'était un truc dans threading peut etre
enfin le truc devait etre fait avant le demarrage de l'appli
j'avais tout essayé, meme en placant le code dans le projet, dans run ...
Mais je dors la nuit, la preuve je me leve à 16h du matin :mouarf:
Thx pour les liens, je vais regarder ca avec interet.
Je viens de faire la modification et le changement de on error vers un try catch et resultat ... ... ... Identique en ce qui concerne les autres forms, dialogs, dlls, etc etc etc ... donc nickel.Citation:
Envoyé par Danyel
Maintenant que j'ai le trycatch en complete solution, je vais voir un peu ce que me renvoi le System.Reflection.MethodBase.GetCurrentMethod.Name maintenant.
Je vous tiens au jus.
Edition 5 minutes plus tards
Comme je le pensais, il me renvoi la sub main (encore logique)
Je me tourne donc vers l'ultime voie de sperot.
Suite au prochain episode :mouarf:
Edition 30 minutes plus tards
Bon sperot, c'est pas glop car c'est pour gerer les ex non geree, mais dans mon cas, c'est pas le cas.
Ca me semble difficile de recuperer le nom de la sub avec cette methode.
ex renvoie la sub qui est en erreur
de plus tu peux retirer ton try catch général et laisser le handler sur les erreurs non catchée (pas conseillé quand meme je pense)
m'enfin ex, tu recupère des tas de choses avec !
Alors pour ceux que ca interesse, voici le code pour récuperer le nom de la form et le nom de la sub, ou l'erreur s'est produite dans une gestion generale d'erreur.
On y a mis le temps, mais on y est arrive :yaisse2:Code:
2
3
4
5
6
7
8
9