Discussion :

[nicocat]

Bonjour,
j'écris une petite bibliothèque C++ et je voudrais que lorsque j'ai des erreurs que j'ai détecté (dimension d'un tableau négative ...),
je voudrais renvoyer l'arbre d'appel des fonctions. c'est_à-dire si on F1(F2(F3(x)), si on a une erreur dans F3, le message d'erreur soit du type
Error in function f1 : Function f2 : function f3 : invalid argument".
J'utilise le méchanisme d'exception mais je suis débutant.
J'ulitise throw et try/catch pour concatener des string ensemble et renvoyer une nouvelle erreur
malheureusement, je ne sais pas comment savoir quel est la fonction appelé la "plus haute",
c'est-à-dire savoir si je dois traiter l'erreur ou la renvoyer a la fonction appelante si il y en a une.

Cordialement,

[Captain'Flam]

Malheureusement, en C++, il n'y a aucun moyen standard de récupérer la "callstack" (pile d'appels).
Mais selon les environnements, tu peux trouver des fonctions non-standards qui permettent de faire ça.
Si tu travailles avec gcc, tu peux utiliser backtrace.
Avec Visual Studio, il y a StackWalk (un peu compliquée).
Dans tous les cas, tout bon moteur de recherche à qui tu demandes "c++ get call stack" te trouvera une foultitude de solutions.

Mais quoi que tu trouves, je te suggère (fortement) de créer une fonction avec des paramètres bien standards et de l'implémenter dans un fichier c++ à part.
Dedans tu pourras faire les #include nécessaires sans "polluer" le reste du code.
Et ça te permettra de circonscrire les "zones non-standard" de ton projet.

[bacelar]

je voudrais renvoyer l'arbre d'appel des fonctions. c'est_à-dire si on F1(F2(F3(x)), si on a une erreur dans F3, le message d'erreur soit du type
Error in function f1 : Function f2 : function f3 : invalid argument".

Juste remarque à 2 balles, là, la séquence d'appel, c'est F3 puis F2 puis F1, il n'y pas de F1+F2+F2 dans la stack d'appel à un aucun moment.

>le Titre du post
Remarque à 2balles bis, arbre d'appel et pile d'appel sont des choses complètement différentes.
La pile d'appel est contient les adresses de retour des fonctions appelantes.
L'arbre d'appel est la liste des fonctions susceptible d'appeler une fonction ou la liste des fonctions appelables par une fonction (en fonction d'un arbre ascendant ou descendant).

Si c'est pour simplifier le débugging, les débogueurs sont capables de faire des choses bien meilleurs que ce que vous pouvez faire avec de simple trace.

Si c'est pour des rapports de problèmes sur le terrain (production), il est bien plus simple et efficace de partir sur une architecture qui utilise un dumper mémoire automatique + fichier des symboles + un watchdog.

En clair, c'est ne STRICTEMENT RIEN FAIRE, pas de try, pas de catch, pas de copier/coller de nom de méthode, RIEN, NADA, QUE TCHI.

L'astuce ?
Sous Windows et sous xNIX, on peut configurer l'OS pour qu'il génère un dump de la mémoire si un programme par en sucette.
Avec le dump mémoire et les symboles de l'exécutable, un compilateur post-mortem indique précisément où c'est parti en sucette et vous avez accès à toute la mémoire de l'exécutable au moment du crash.
Mais pour ça, il ne faut pas catcher tout et n'importe quoi et il faut utiliser correctement les capsules RAII pour fermer l'application en bon ordre.
Le watchdog est là pour relancer l'application qui a planté.

Ce genre d’infrastructure est donné clé en main sous Windows avec des outils type AutoDumpPlus (ADPlus).
https://msdn.microsoft.com/en-us/lib...or=-2147217396

[dragonjoker59]

Et sinon, c'est quand même possible de le faire, mais en C, et pas portable.
En API Win32, il y a les fonctions SymInitialize et SymFromAddr qui te permettront de récupérer la pile d'appel.
Sous Linux, il y a les fonctions backtrace et backtrace_symbols, qui font le même travail.
Sous Mac, j'en sais rien, mais je soupçonne que backtrace et backtrace_symbols doivent fonctionner.

[bacelar]

En API Win32, il y a les fonctions SymInitialize et SymFromAddr qui te permettront de récupérer la pile d'appel.

Pour que ces appels fonctionnent, il faut que les symboles soient disponible sur la machine d'exécution, c'est très moyen pour un environnement de prod, et je crois qu'il faut que des Dll uniquement distribuées avec le Redistrubution-Kit de Debug.

Je ne vois pas pourquoi vous voulez vous obstiner à faire du boulot en plus.

[dragonjoker59]

... je crois qu'il faut que des Dll uniquement distribuées avec le Redistrubution-Kit de Debug...

Je suis tout à fait d'accord, et ça ne sert qu'à ça.
Je ne m'en sers que pour connaître les piles d'appel d'allocation des objets que je traque, ce que je ne suis pas sûr d'avoir avec un crash dump.

[bacelar]

, ce que je ne suis pas sûr d'avoir avec un crash dump

Why ???

[dragonjoker59]

Ben en tout cas avec un .dmp pour Visual Studio, je ne l'ai pas.

[bacelar]

Moi, pour les dump, j'utilise WinDbg mais je crois que VS sait les lire depuis un bon bout de temps.