Version imprimable
bonjour,
je travaille avec gcc
voila si j'ai
ca plante mon programme et donc ça ne passe pas dans le catchCode:
2
3
4
5
si j'ai
j'aimerais savoir comment capturer les exception dans le premier casCode:
2
3
4
5
merci
salut !
throw sans argument est une syntaxe spéciale qui redirige une exception au niveau supérieur. Exemple:
Si tu ne pouvais pas faire ça, alors ça voudrait dire que le catch niveau 2 devrait regénérer exactement la même exception, ce qui n'est pas forcément évident.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Dans ton cas, ton bloc try essaye de rebalancer une exception au niveau supérieur, mais il n'y en a aucune en cours, donc ça plante.
Qu'est-ce que tu essayes de faire ?
ben en fait c'est pour capturer des exceptions du style
mais plus généralement pour capturer des exceptions du systemCode:
2
(le printf est juste a titre d'exemple, je sais très bien que ça va planter lol, mais j'aimerais capturer l'exception)
Comme la dit phi1981 ton premier code actuel est invalide.
throw; sert à relancer une exception, ça implique qu'une exception doit être en cours de traitement, dit autrement ce morceau de code doit se trouver dans un bloc catch. Dans le cas contraire std::terminate est appelé (si c'est le comportement de std::terminate que tu veux changer, alors cherche du côté de std::set_terminate).
Donc pour faire simple, tu ne dois jamais écrire ton premier code.
Si ta question concerne particulièrement les exceptions systèmes, dans ce cas tu ne trouveras rien dans le C++ standard, puisque les exceptions systèmes vont dépendre du système. Il faudra donc dans tout les cas passer par une bibliothèque externe, pour windows je suppose que c'est dans la MSDN, pour linux ce doit être un en-tête à inclure que tu devrais trouver avec les mots clés "signal handling".
Pour Windows :
Même s'il est possible de "catcher" tout et n'importe quoi, il ne faut JAMAIS le faire.
On ne catch que ce que l'on sait traiter (loger n'est pas traiter).
Si vous voulez avoir des informations en cas de crash, utilisez les utilitaires de génération automatique de dump comme Dr. Watson ou ADPlus.
Avec ces dumps et les fichiers PDB générés pendant la compilation, vous pouvez avoir une vue exacte du programme et de ça mémoire au moment exacte du crash.
Si vous voulez réduire l'interruption de service du programme planté, faites en un service Windows ou utilisez un simple Watch Dog pour relancer automatiquement le programme.
Note: Je ne vois pas d'inconvénient à catcher pour loguer ce qu'on ne peut pas traiter du moment qu'on relance ensuite.Citation:
Envoyé par bacelar
Ca nique la callstack, la statck-trace de l'exception, et on ne log rien ou presque, on ne va pas comparer le dump de tout l'espace mémoire du programme, (tout threads, toutes stacks confondus (User et Kernel)) avec le log d'un pauvre message d'erreur à 2 balles avec la valeur de 3 variables maximums (pour les moins flemmards). :weird:
Les logs fonctionnels oui, les logs techniques avant crash, C'EST DE LA MERDE. :zoubi:
en fait le problème principal que j'ai sur g++ (gcc 4.4.6)
c'est que lorsque que je fais
la ptrlist étant une map<string, void *>*Code:
2
3
4
5
6
7
8
et que la clef n'existe pas dans la map
ca plante carrément le logiciel
or sur visual studio en collant /EHsc j'arrive a capturer le même type d'erreur
je sais je pourrais utiliser un iterateur avec find... pour vérifier si la clef existe
Qu'est-ce que tu veux dire par "capturer"? Parce que normalement, en /EHsc, un catch(...) n'attrape pas une exception non-C++... il faut /EHa pour ça.Citation:
Envoyé par ikeas
oui c'est peut etre le /EHa
ce que j'aimerais faire c'est aussi la capturer avec gcc sur unix
C'est peut-être ce que tu aimerais faire, mais ce n'est pas ce qu'il faut que tu fasses. Donc, ça tombe bien que ce soit impossible.
Ce qu'il faut que tu fasses, c'est corriger ton code pour ne pas causer de comportement indéfini (l'Access Violation étant une conséquence possible de ce CI. Dans d'autres circonstances, tu pourrais avoir droit aux démons nasaux à la place). Donc oui, tu dois faire un vrai find(). Et en cas d'échec du find, provoquer un comportement défini, comme retourner NULL ou lancer une vraie exception C++.
ben oui c'est ce que j'ai fait
bon c'est dommage que l'on puisse pas tout capturer :calim2:
Tu n'es pas censé pouvoir te reposer sur des comportements indéfinis.
Les exceptions C++ sont définies. Le déréférencement de pointeur invalide ne l'est pas.
En résumé, t'oublie "catch(...)". :aie:
oui ca j'avais compris :lol:
ceci étant quand mon programme plante lamentablement et sans m'informer je trouve ça assez désobligeant !!!
Si t'utilises un debuger, il prend normalement la main quand le programme crash.
S'il se relance automatiquement et revient dans un état stable, réactif, et sans perdre le boulot d'une journée et sans avoir vérolé vos données, c'est bien mieux que d'avoir un message tout moisi "je suis dans les fraises, je bloque tous les fichiers dans un état incohérent et tu peux toujours essayer de me killer via le gestionnaire des tâches, Skynet vaincra".
comme j'utilise Eclipse en mode debug
j'ai .............. rien
evidement j'ai un beau vidage de stack de temps a autre mais pas super explicite
du style
claire hein :ptdr:Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
Heu, si tu trouve ça pas claire, faudrait lire un peu la documentation là. 8O
Je ne pense pas qu'un message de la C-Runtime peu être plus clair : au moment d'un delete sur 0x000000000060ad60, ça part en sucette.:mouarf:Citation:
*** glibc detected *** /home/dev/workspace_bruno/ZTest/Debug/ZTest: double free or corruption (!prev): 0x000000000060ad60 ***
Si tu vois pas où, bin t'as la callstack et avec les symboles et les sources, t'as la ligne qui déconne. :aie:
On peut difficilement faire plus simple. :weird:
Et vu que ça se fait lors du exit(), l'erreur est donc quelque part dans le destructeur d'un objet statique/global.