Discussion :

[ikeas]

bonjour,

je travaille avec gcc

voila si j'ai

Code :

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

1
2
3
4
5
try {
     throw ;
} catch (...) {
     cout << "catch error" << endl;
}

ca plante mon programme et donc ça ne passe pas dans le catch

si j'ai

Code :

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

1
2
3
4
5
try {
      throw 1;
} catch (...) {
      cout << "catch throw 1" << endl;
}

j'aimerais savoir comment capturer les exception dans le premier cas
merci

[phi1981]

salut !

throw sans argument est une syntaxe spéciale qui redirige une exception au niveau supérieur. Exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
try {  // Try niveau 1
     fonction ();
     try {   // Try niveau 2
          while (yes)
          {
                 if (something())
                        throw mon_exception();
          }
     }
     catch (...)  // catch niveau 2
     {
         if (peut_faire_qqchose() == false)
         {
              std::cout << "Oh heu ... Une exception a été générée, mais je sais pas quoi en faire en fait. Je vais juste la rebalancer au niveau supérieur\n";
             throw;
     }
}
catch (std::exception& ex) // catch niveau 1
{
      std::cout << "Ah ici je sais quoi faire de cette exception. Je vais m'en occuper\n";
}

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.

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 ?

[ikeas]

ben en fait c'est pour capturer des exceptions du style

Code :

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

1
2
string s = "toto";
printf("%s", s);

mais plus généralement pour capturer des exceptions du system
(le printf est juste a titre d'exemple, je sais très bien que ça va planter lol, mais j'aimerais capturer l'exception)

[Flob90]

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".

[bacelar]

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.

[Médinoc]

On ne catch que ce que l'on sait traiter (loger n'est pas traiter).

Note: Je ne vois pas d'inconvénient à catcher pour loguer ce qu'on ne peut pas traiter du moment qu'on relance ensuite.

[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).

Les logs fonctionnels oui, les logs techniques avant crash, C'EST DE LA MERDE.

[ikeas]

en fait le problème principal que j'ai sur g++ (gcc 4.4.6)
c'est que lorsque que je fais

Code :

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

1
2
3
4
5
6
7
8
 static Interface* newInstance(string s) {
  try {
    Interface* i = (Interface*) (*ptrlist)[s]->create();
    return i;
  } catch (...) {
    return NULL;
  }
}

la ptrlist étant une map<string, void *>*
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

[Médinoc]

or sur visual studio en collant /EHsc j'arrive a capturer le même type d'erreur

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.

[ikeas]

oui c'est peut etre le /EHa
ce que j'aimerais faire c'est aussi la capturer avec gcc sur unix

[Médinoc]

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++.

[ikeas]

ben oui c'est ce que j'ai fait
bon c'est dommage que l'on puisse pas tout capturer

[Médinoc]

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.

[bacelar]

En résumé, t'oublie "catch(...)".

[ikeas]

oui ca j'avais compris
ceci étant quand mon programme plante lamentablement et sans m'informer je trouve ça assez désobligeant !!!

[Bousk]

Si t'utilises un debuger, il prend normalement la main quand le programme crash.

[bacelar]

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".

[ikeas]

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

Code :

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

1
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
*** glibc detected *** /home/dev/workspace_bruno/ZTest/Debug/ZTest: double free or corruption (!prev): 0x000000000060ad60 ***
======= Backtrace: =========
/lib64/libc.so.6[0x34fa075916]
/lib64/libc.so.6[0x34fa078443]
/usr/lib64/libstdc++.so.6(_ZNSsD1Ev+0x39)[0x350149d4a9]
/lib64/libc.so.6(exit+0xe2)[0x34fa035db2]
/lib64/libc.so.6(__libc_start_main+0x104)[0x34fa01ece4]
/home/dev/workspace_bruno/ZTest/Debug/ZTest[0x402399]
======= Memory map: ========
00400000-00409000 r-xp 00000000 fd:02 10879913                           /home/dev/workspace_bruno/ZTest/Debug/ZTest
00609000-0060a000 rw-p 00009000 fd:02 10879913                           /home/dev/workspace_bruno/ZTest/Debug/ZTest
0060a000-0062b000 rw-p 00000000 00:00 0                                  [heap]
34f9800000-34f9820000 r-xp 00000000 fd:00 655384                         /lib64/ld-2.12.so
34f9a1f000-34f9a20000 r--p 0001f000 fd:00 655384                         /lib64/ld-2.12.so
34f9a20000-34f9a21000 rw-p 00020000 fd:00 655384                         /lib64/ld-2.12.so
34f9a21000-34f9a22000 rw-p 00000000 00:00 0
34f9c00000-34f9c02000 r-xp 00000000 fd:00 655884                         /lib64/libdl-2.12.so
34f9c02000-34f9e02000 ---p 00002000 fd:00 655884                         /lib64/libdl-2.12.so
34f9e02000-34f9e03000 r--p 00002000 fd:00 655884                         /lib64/libdl-2.12.so
34f9e03000-34f9e04000 rw-p 00003000 fd:00 655884                         /lib64/libdl-2.12.so
34fa000000-34fa189000 r-xp 00000000 fd:00 655388                         /lib64/libc-2.12.so
34fa189000-34fa389000 ---p 00189000 fd:00 655388                         /lib64/libc-2.12.so
34fa389000-34fa38d000 r--p 00189000 fd:00 655388                         /lib64/libc-2.12.so
34fa38d000-34fa38e000 rw-p 0018d000 fd:00 655388                         /lib64/libc-2.12.so
34fa38e000-34fa393000 rw-p 00000000 00:00 0
34fa800000-34fa883000 r-xp 00000000 fd:00 655390                         /lib64/libm-2.12.so
34fa883000-34faa82000 ---p 00083000 fd:00 655390                         /lib64/libm-2.12.so
34faa82000-34faa83000 r--p 00082000 fd:00 655390                         /lib64/libm-2.12.so
34faa83000-34faa84000 rw-p 00083000 fd:00 655390                         /lib64/libm-2.12.so
3500000000-3500016000 r-xp 00000000 fd:00 655905                         /lib64/libgcc_s-4.4.6-20120305.so.1
3500016000-3500215000 ---p 00016000 fd:00 655905                         /lib64/libgcc_s-4.4.6-20120305.so.1
3500215000-3500216000 rw-p 00015000 fd:00 655905                         /lib64/libgcc_s-4.4.6-20120305.so.1
3501400000-35014e8000 r-xp 00000000 fd:00 1104280                        /usr/lib64/libstdc++.so.6.0.13
35014e8000-35016e8000 ---p 000e8000 fd:00 1104280                        /usr/lib64/libstdc++.so.6.0.13
35016e8000-35016ef000 r--p 000e8000 fd:00 1104280                        /usr/lib64/libstdc++.so.6.0.13
35016ef000-35016f1000 rw-p 000ef000 fd:00 1104280                        /usr/lib64/libstdc++.so.6.0.13
35016f1000-3501706000 rw-p 00000000 00:00 0
7ffff7fc2000-7ffff7fc8000 rw-p 00000000 00:00 0
7ffff7ffb000-7ffff7ffe000 rw-p 00000000 00:00 0
7ffff7ffe000-7ffff7fff000 r-xp 00000000 00:00 0                          [vdso]
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0                          [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

claire hein

[bacelar]

Heu, si tu trouve ça pas claire, faudrait lire un peu la documentation là.

*** glibc detected *** /home/dev/workspace_bruno/ZTest/Debug/ZTest: double free or corruption (!prev): 0x000000000060ad60 ***

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.

Si tu vois pas où, bin t'as la callstack et avec les symboles et les sources, t'as la ligne qui déconne.

On peut difficilement faire plus simple.

[Médinoc]

Et vu que ça se fait lors du exit(), l'erreur est donc quelque part dans le destructeur d'un objet statique/global.