Exception passant à travers les catch

Bonjour,

Je teste actuellement une application sous Windows et j'ai un petit problème sur ce bout de code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

try { std::cerr << "debut" << std::endl; std::cerr.flush(); boost::filesystem3::copy( path, boost::filesystem3::path("temp_PDF") / path.filename() ); std::cerr << "fin" << std::endl; std::cerr.flush(); } catch ( boost::filesystem3::filesystem_error e ) { std::cerr << "except" << std::endl; std::cerr.flush(); } catch ( ... ) { std::cerr << "erreur 1" << std::endl; std::cerr.flush(); }

---

catch(...) étant censé, il me semble, pouvoir rattraper toutes les exceptions.
Ce que je n'arrive pas à m'expliquer, c'est que la ligne :

Code:

---

boost::filesystem3::copy( path, boost::filesystem3::path("temp_PDF") / path.filename() );

---

lance une exception qui n'est pas attrapée...

Voici ce que j'ai à l'écran :

Citation:

---

debut
terminate after throwing an instance of 'boost::filesystem::filesystem_error'
what() : [...]

This application has requested the Runtime to terminate it in a unusual way.
Please contact the application's support team for more information.

---

Je ne sais pas si c'est lié mais je ne peux pas lancer mon application deux fois de suite dans la même console DOS ( l'application retourne directement sans rien faire).
J'ai aussi, quand l'exception n'est pas lancée, un system() qui n'exécute pas la commande passée en argument :aie:.

Est-ce que vous auriez une idée ?

Pour l'instant je note juste que tu catch l'exception par copie et je me demande si c'est pas un probleme.

Sinon, je suis pas specialiste mais il ne se pourait pas qu'il y ait un appel direct a terminate() a cause d'une exception qui se lance dans un catch?

par ailleurs, pourquoi flusher après un <<std::endl.

std::endl fait le flush.

Citation:

---

Envoyé par leternel

par ailleurs, pourquoi flusher après un <<std::endl.

std::endl fait le flush.

---

Malheureusement pas toujours :aie:

Quand on exécute un programme dans la console de QtCreator, le std::endl ne flush pas toujours.
J'ai donc pris l'habitude de mettre un std::cerr.flush() pour m'éviter toutes mauvaises surprises.

Citation:

---

Pour l'instant je note juste que tu catch l'exception par copie et je me demande si c'est pas un probleme.

---

J'attrape le même type d'exceptions sans problème sous Linux, donc je ne pense pas que ce soit ça.
De plus, même si l'exception n'est pas rattrapée par le premier catch, elle devrait obligatoirement l'être par le second non?

Citation:

---

Sinon, je suis pas specialiste mais il ne se pourait pas qu'il y ait un appel direct a terminate() a cause d'une exception qui se lance dans un catch?

---

Il n'y a pas d'exceptions qui se lancent dans un catch ici il me semble non?
Si la copie est interdite, il devrait théoriquement directement passer au catch suivant.

J'essaye de passer par référence pour voir ce que cela donne ;)

EDIT : même en passant par référence constante au lieu de la copie, rien ne change.

J'ai oublié de le préciser, mais sous Windows, j'ai fait un :

Code:

---

#define filesystem3 filesystem

---

Car sous Windows, filesystem3 n'existe pas.

Tu linkes en statique ou dynamique? Ca me fait penser à des problèmes d'exceptions qui franchissent des DLL boundaries...

Les linkages sont en dynamiques (utilisations de .dll)

Bonjour.

Un Debug pas-à-pas, cela dit quoi ? Il semblerai que la biblio Boost joue des coups tordus.

Avez-vous essayé :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

try { std::cerr << "debut" << std::endl; std::cerr.flush(); boost::filesystem3::copy( path, boost::filesystem3::path("temp_PDF") / path.filename() ); std::cerr << "fin" << std::endl; std::cerr.flush(); } catch ( ... ) { std::cerr << "erreur 1" << std::endl; std::cerr.flush(); }

---

Bonjour,

J'ai essayé avec votre solution mais en mode pas à pas, le résultat est le même, dès qu'on arrive à la ligne de la copie, on quitte directement le programme lors de la copie si le fichier est déjà existant.

l'exception est lancée dans la méthode "error" de operation.cpp qui lance une exception grâce à la macro BOOST_FILESYSTEM_THROW(EX) qui se contente de faire un throw EX

Il faut que tu fasses du pas a pas apres le throw. Je suis presque sur que l'une des conditions pour que terminate() ou abort() soit appele est rencontre.

Citation:

---

Envoyé par Neckara

Bonjour,
l'exception est lancée dans la méthode "error" de operation.cpp qui lance une exception grâce à la macro BOOST_FILESYSTEM_THROW(EX) qui se contente de faire un throw EX

---

Donc ça vient du côté DLL? J'ai remarqué que les exceptions venant de DLL ne sont pas gérables côté appelant dans le cas général (les exceptions cross-boundary marchent si compatibilité binaire parfaite compilé des deux côtés avec le même compilo et les mêmes options).

Citation:

---

Envoyé par Klaim

Il faut que tu fasses du pas a pas apres le throw. Je suis presque sur que l'une des conditions pour que terminate() ou abort() soit appele est rencontre.

---

Malheureusement, dès que l'exception est lancée, le programme sort, je ne peux pas aller plus loin.

Citation:

---

Envoyé par therwald

Donc ça vient du côté DLL? J'ai remarqué que les exceptions venant de DLL ne sont pas gérables côté appelant dans le cas général (les exceptions cross-boundary marchent si compatibilité binaire parfaite compilé des deux côtés avec le même compilo et les mêmes options).

---

Oui, c'est bien du côté DLL. Pour la compilation, il est possible que ce ne soit pas exactement la même version de mingw ( gcc 4.7.1 vs mingw 4.7.2 peut-être).

J'essayerais de me générer un makefile pour le compiler avec le gcc installé sous Windows.

En tout cas le code en soit n'est pas problématique, je l'ai testé directement dans un main avec un path construit par défaut, et l’exception est bien rattrapé. Tu as essayé de compiler en link statique ?

gcc 4.7.1 présente de gros problèmes de compatibilité au niveau de l'ABI.

J'ai changé le compilateur pour mon gcc, rien ne change.

D'après QtCreator, l'ABI serait identique.
De plus mingw et gcc sont tous les deux à la version 4.7.2 donc le problème semble ne pas venir des compilateurs.

Après, boost (compilé avec mon gcc) ne "supporte pas officiellement" mingw, le problème pourrait donc venir de là?
Mais ceci pose pas mal de problèmes si on ne peut plus utiliser d'exceptions :aie:

Sous Windows en tout cas, les exceptions n'ont jamais été encouragées cross-DLL. D'où la méthode COM de trapper les exceptions, retourner des HRESULT et des IErrorInfo à la place, et laisser l'appelant relancer l'exception.

Comme le dit Flob90, as-tu essayé en statique?

Edit: C'est vraiment très improbable, mais y a-t-il une spécification d'exception dans la déclaration de copy() ?

Citation:

---

Envoyé par Klaim

Il faut que tu fasses du pas a pas apres le throw. Je suis presque sur que l'une des conditions pour que terminate() ou abort() soit appele est rencontre.

---

En fait, je ne pense pas. Quant terminate est appelé suite à double throw, tu ne vois pas le message disant que le programme termine suite à l'exception XXX, il termine, point.
Comme dit medinoc, quand je veux de la gestion d'exception à travers une DLL boundary, je fais un catch côté DLL, je transmets l'erreur par la valeur de retour, et je rethrow. Quand je peux, j'automatise le rethrow en utilisant un header de DLL qui expose une fonction publique qui le fait. Comme ce code est compilé côté appelant, l'exception est correctmeent gérée par la suite.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

struct retour{ int valeur; int codeErreur; } int function(int parm){ retour val; _functionImpl(pam,&val); switch(codeErreur){ case 0: return retour.valeur; case 1: throw ExceptionType1(); case 2: throw ExceptionType1(); default: throw UnexpectedException(); } }; void _functionImpl(int parm, retour * retour);

---

Ce genre de chose (tu peux raffiner si tu veux sortir plus d'info dans ton exception)

Citation:

---

Envoyé par Médinoc

Sous Windows en tout cas, les exceptions n'ont jamais été encouragées cross-DLL. D'où la méthode COM de trapper les exceptions, retourner des HRESULT et des IErrorInfo à la place, et laisser l'appelant relancer l'exception.

---

C'est quand même un comportement ridicule, est-ce qu'ils ont au moins un début de raison de vouloir faire cela ?

Citation:

---

Envoyé par Médinoc

Comme le dit Flob90, as-tu essayé en statique?

---

J'ai tenté mais apparemment il faut que je recompile en statique boost. Or je n'ai plus que quelques heures avant de rendre ce projet ( heureusement, les exceptions avec boost ne devraient pas survenir ).

C'est tout de même problématique, pour un autre projet que je fais, il va donc falloir éviter toutes les exceptions et les lancées qu'au niveau de l'appellant ? ça va être invivable.
De plus, si je veux utiliser des dll pour permettre des mises à jours plus légère en ne remplaçant que les dll modifiées, je ne pourrais pas compiler en statique.

Citation:

---

Edit: C'est vraiment très improbable, mais y a-t-il une spécification d'exception dans la déclaration de copy() ?

---

Vous voulez dire un throw indiqué dans le prototype ? Dans ce cas là non, il n'y a pas de spécification d'exception.

Tu peux choisir quoi recompiler de boost, et même en prenant tout ce n'est pas si long (typiquement tu le lances et tu continues de réfléchir pendant ce temps).

Comme autre tests tu pourrais aussi essayer de localiser très exactement le problème et faire un mini-projet qui ne montre que ce problème. Par exemple, compile juste un main avec :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

#include<iostream> #include<boost\filesystem.hpp>   int main(){ try{ boost::filesystem::copy(boost::filesystem::path(),boost::filesystem::path()); } catch (boost::filesystem::filesystem_error e){ std::cout<<1; } }

---

Et compile le exactement comme ton projet. Tu seras certain que ça vient bien du linkage et pas d'autre chose (tu as pas d'option de compilation exotique qui désactiverait les catch, même indirectement, ou quelque chose du genre ?).

Edit: Pour l'ABI, normalement c'est même compilateur et même option, sauf indication contraire de compatibilité par ton compilateur. Mais je crois que la spec ABI de gcc est assez large et a une plage de compatibilité assez grande (donc si t'as pas choisit des options étranges, ça doit aller).

Citation:

---

Envoyé par Neckara

C'est quand même un comportement ridicule, est-ce qu'ils ont au moins un début de raison de vouloir faire cela ?

---

C'est très simple, les DLLs peuvent être écrites et appelées dans différents langages (C++, Visual Basic <= 6.0, et bien plus encore dans le cas de COM), dont les exceptions ne sont pas implémentées de la même manière. Le langage C par exemple, ne sait pas du tout ce qu'est une exception!

Mais sous Linux ça marche parfaitement pourtant :koi:

Tu veux dire sous Linux où pratiquement tout est compilé avec GCC?

boost et mon programme ont tous deux été compilés avec gcc sous Windows pourtant.

Mais pas le kernel de Windows.
Et surtout, pas la C Run-Time Library de Microsoft (MSVCRT.DLL) sur laquelle MinGW s'appuie.

Et après on se demande pourquoi Windows est continuellement trollée...

Donc je vais être obligé d'utiliser des codes de "retourner des exceptions" au lieu de les lancer :aie:

Ce n'est pas la faute de Microsoft si GCC piggyback sur la bibliothèque runtime des compilateurs concurrents (ce qui n'est vraiment pas recommandé pour des raisons d'ABI).
Un des symptômes est visible parce que GCC et Microsoft n'utilisent pas la même taille de long double:

Code:

---

1 2 3 4 5 6 7 8 9 10

#include <stdio.h>   int main(void) { long double ld = 42.1234; printf("double: %d\n", (int)sizeof(double)); printf("long double: %d\n", (int)sizeof(long double)); printf("Valeur long double (%%Lf): %Lf\n", ld); return 0; }

---

Code:

---

1 2 3

double: 8 long double: 8 Valeur long double (%Lf): 42.123400

---

Code:

---

1 2 3

double: 8 long double: 12 Valeur long double (%Lf): -0.000000

---

Si MinGW ne faisait pas ça, ce serait son ABI de bout en bout, et ses exceptions pourraîent être propagées d'une DLL MinGW à l'autre... et ses long double s'afficheraient correctement.

Je viens de tester avec boost en link dynamic avec mingw 4.7.1 (tdm), aucun problème. Quel est ta version de compilateur ?

Edit: Fonction aussi avec mingw 4.7.2.

Version de boost : 1.53

Version de g++ :

Citation:

---

Built by Equation Solution <http://www.Equation.com>.
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=c:/bin/gcc/bin/../libexec/gcc/i686-pc-mingw32/4.7.2/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../gcc-4.7.2-mingw/configure --host=i686-pc-mingw32 --build=x86_64-unknown-linux-gnu --target=i686-pc-mingw32 --prefix=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gcc/4.7.2 --with-gcc --with-gnu-as --with-gnu-ld --with-cloog=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/cloog --with-gmp=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/gmp --with-mpfr=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpfr --with-mpc=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/mpc --enable-cloog-backend=ppl --with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cross/x86_32/gcc/4.7.2 --disable-shared --disable-nls --disable-tls --disable-win32-registry --enable-libquadmath-support --enable-libquadmath --enable-languages=c,c++,fortran --enable-libgomp --enable-threads=win32 --enable-lto --enable-static --enable-shared=lto-plugin --enable-plugins --with-host-libstdcxx='-lstdc++ -lsupc++ -lm' --with-ppl=/home/gfortran/gcc-home/binary/mingw32/native/x86_32/ppl --enable-ld=yes
Thread model: win32
gcc version 4.7.2 (GCC)

---

Avec le code minimal donné par Flob90, toujours le même problème.

Le problème venait du mingw que j'avais trouvé, apparemment il avait été compilé avec des options exotiques.

J'ai téléchargé le mingw officiel puis j'ai recompilé boost et je n'ai plus aucun problème, merci à vous tous.