Remplacement d'exeption dans une librairie statique sur Solaris
2 réponses
Benoit
Bonjour
Voici le probl=E8me auquel je suis confront=E9. J'ai am=E9lior=E9 une
librairie existante dans mon projet, en rempla=E7ant une fonction en C
par une fonction plus rapide en C++.
J'ai profit=E9 de ce remplacement pour utiliser des exceptions dans le
code C++ pour g=E9rer les cas d'erreurs. J'ai fait des tests avec cette
librairie et tout fonctionne pour le mieux. Surtout dans les cas
d'erreurs o=F9 mes exceptions sont correctement "catch=E9es" par le code
de r=E9cup=E9ration d'erreur. Tout irait pour le mieux dans le meilleur
des mondes si je ne devais pas int=E9grer ces librairies modifi=E9es dans
un projet plus gros, utilisant COOL:Gen.
En effet, alors que tout se passe pour le mieux dans mon petit projet,
lorsque j'int=E9gre ces librairies dans le projet COOL:Gen, la gestion
des exceptions cod=E9es par moi est remplac=E9 par la gestion par
d=E9faut, qui est terminate(), puis abort et core dump !
POur illustrer ce que j'ai, voici un exemple de code :
main ()
{
try
{
CBinMAnager aBinManager ;
CBin abin =3D aBinManager.find (parameter1, paramater2) ; // C'est
la nelle
//
fonction
aBin.DisplayContent () ;
}
catch (CMyExceptionClass& e)
{
std::cout << e.what() << std::endl ;
}
}
Dans mon environnement, en cas d'erreur, j'ai bien le message d'erreur
normale et le programme sort normalement. Parfait !
Par contre, lorsque j'int=E9gre la librairie dans le projet principal,
et que je construit les binaires via COOL:Gen, j'ai un terminate(),
avec abort() et core dump.
Euh, j'ai un peu oublié quelques informations techniques.
Je travaille sur Solaris 2.8, compilation avec le C++ de forte 6.2 patch 2.
Les autres langagues sont aussi ceux de forte 6.2 patch 2.
Enfin, nous utllisons Oracle 8, 64 bits, et COOL:Gen 6.5.
Merci d'avance de votre aide
Cordialement
Benoit
kanze
Benoit wrote:
Voici le problème auquel je suis confronté. J'ai amélioré une librairie existante dans mon projet, en remplaçant une fonction en C par une fonction plus rapide en C++.
J'ai profité de ce remplacement pour utiliser des exceptions dans le code C++ pour gérer les cas d'erreurs. J'ai fait des tests avec cette librairie et tout fonctionne pour le mieux. Surtout dans les cas d'erreurs où mes exceptions sont correctement "catchées" par le code de récupération d'erreur. Tout irait pour le mieux dans le meilleur des mondes si je ne devais pas intégrer ces librairies modifiées dans un projet plus gros, utilisant COOL:Gen.
En effet, alors que tout se passe pour le mieux dans mon petit projet, lorsque j'intégre ces librairies dans le projet COOL:Gen, la gestion des exceptions codées par moi est remplacé par la gestion par défaut, qui est terminate(), puis abort et core dump !
POur illustrer ce que j'ai, voici un exemple de code :
main () { try { CBinMAnager aBinManager ; CBin abin = aBinManager.find (parameter1, paramater2) ; // C'est la nelle // fonction aBin.DisplayContent () ; } catch (CMyExceptionClass& e) { std::cout << e.what() << std::endl ; } }
Dans mon environnement, en cas d'erreur, j'ai bien le message d'erreur normale et le programme sort normalement. Parfait !
Par contre, lorsque j'intégre la librairie dans le projet principal, et que je construit les binaires via COOL:Gen, j'ai un terminate(), avec abort() et core dump.
La résponse évidante, c'est qu'il n'y a pas de catch autour du throw. Sans savoir ce que fait COOL:Gen, c'est difficile à dire pourquoi. Qui appelle CBinManater::find, et où? (Pour que le catch soit effectif, il faut qu'il soit dans une fonction qui appelle la fonction qui lève l'exception. Et dans le même thread, évidement.)
D'avance merci de votre aide/remarques/réfléxtions
Je vois deux possibilités immédiates : que l'appel de la fonction qui lève l'exception a lieu dans un autre thread, ou qu'il a lieu dans un call-back qui travers du code C, voire des appels système. (Je ne sais pas si ce seconde serait réelement un problème avec les outils Sun, mais c'est une possibilité.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Benoit wrote:
Voici le problème auquel je suis confronté. J'ai amélioré une
librairie existante dans mon projet, en remplaçant une
fonction en C par une fonction plus rapide en C++.
J'ai profité de ce remplacement pour utiliser des exceptions
dans le code C++ pour gérer les cas d'erreurs. J'ai fait des
tests avec cette librairie et tout fonctionne pour le mieux.
Surtout dans les cas d'erreurs où mes exceptions sont
correctement "catchées" par le code de récupération d'erreur.
Tout irait pour le mieux dans le meilleur des mondes si je ne
devais pas intégrer ces librairies modifiées dans un projet
plus gros, utilisant COOL:Gen.
En effet, alors que tout se passe pour le mieux dans mon petit
projet, lorsque j'intégre ces librairies dans le projet
COOL:Gen, la gestion des exceptions codées par moi est
remplacé par la gestion par défaut, qui est terminate(), puis
abort et core dump !
POur illustrer ce que j'ai, voici un exemple de code :
main ()
{
try
{
CBinMAnager aBinManager ;
CBin abin = aBinManager.find (parameter1, paramater2) ; // C'est la nelle
// fonction
aBin.DisplayContent () ;
}
catch (CMyExceptionClass& e)
{
std::cout << e.what() << std::endl ;
}
}
Dans mon environnement, en cas d'erreur, j'ai bien le message
d'erreur normale et le programme sort normalement. Parfait !
Par contre, lorsque j'intégre la librairie dans le projet
principal, et que je construit les binaires via COOL:Gen, j'ai
un terminate(), avec abort() et core dump.
La résponse évidante, c'est qu'il n'y a pas de catch autour du
throw. Sans savoir ce que fait COOL:Gen, c'est difficile à dire
pourquoi. Qui appelle CBinManater::find, et où? (Pour que le
catch soit effectif, il faut qu'il soit dans une fonction qui
appelle la fonction qui lève l'exception. Et dans le même
thread, évidement.)
D'avance merci de votre aide/remarques/réfléxtions
Je vois deux possibilités immédiates : que l'appel de la
fonction qui lève l'exception a lieu dans un autre thread, ou
qu'il a lieu dans un call-back qui travers du code C, voire des
appels système. (Je ne sais pas si ce seconde serait réelement
un problème avec les outils Sun, mais c'est une possibilité.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Voici le problème auquel je suis confronté. J'ai amélioré une librairie existante dans mon projet, en remplaçant une fonction en C par une fonction plus rapide en C++.
J'ai profité de ce remplacement pour utiliser des exceptions dans le code C++ pour gérer les cas d'erreurs. J'ai fait des tests avec cette librairie et tout fonctionne pour le mieux. Surtout dans les cas d'erreurs où mes exceptions sont correctement "catchées" par le code de récupération d'erreur. Tout irait pour le mieux dans le meilleur des mondes si je ne devais pas intégrer ces librairies modifiées dans un projet plus gros, utilisant COOL:Gen.
En effet, alors que tout se passe pour le mieux dans mon petit projet, lorsque j'intégre ces librairies dans le projet COOL:Gen, la gestion des exceptions codées par moi est remplacé par la gestion par défaut, qui est terminate(), puis abort et core dump !
POur illustrer ce que j'ai, voici un exemple de code :
main () { try { CBinMAnager aBinManager ; CBin abin = aBinManager.find (parameter1, paramater2) ; // C'est la nelle // fonction aBin.DisplayContent () ; } catch (CMyExceptionClass& e) { std::cout << e.what() << std::endl ; } }
Dans mon environnement, en cas d'erreur, j'ai bien le message d'erreur normale et le programme sort normalement. Parfait !
Par contre, lorsque j'intégre la librairie dans le projet principal, et que je construit les binaires via COOL:Gen, j'ai un terminate(), avec abort() et core dump.
La résponse évidante, c'est qu'il n'y a pas de catch autour du throw. Sans savoir ce que fait COOL:Gen, c'est difficile à dire pourquoi. Qui appelle CBinManater::find, et où? (Pour que le catch soit effectif, il faut qu'il soit dans une fonction qui appelle la fonction qui lève l'exception. Et dans le même thread, évidement.)
D'avance merci de votre aide/remarques/réfléxtions
Je vois deux possibilités immédiates : que l'appel de la fonction qui lève l'exception a lieu dans un autre thread, ou qu'il a lieu dans un call-back qui travers du code C, voire des appels système. (Je ne sais pas si ce seconde serait réelement un problème avec les outils Sun, mais c'est une possibilité.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
