Discussion :

[koala01]

Salut,

J'ai cr�� une biblioth�que de classes qui fonctionne bien... du moins tant qu'elle reste en statique.

Maintenant, j'aimerais donner la possibilit� de la compiler sous la forme d'une biblioth�que partag�e.

Les directives pr�processeurs semblent correctes et il m'est donc possible de cr�er une biblioth�que partag�e ou une biblioth�que statique sur les diff�rent OS test�s (du moins, j'arrive � obtenir la dll, le so, et/ou le .a, selon le syst�me).

L� o� cela coince, c'est que cette biblioth�que est sens�e lancer des exceptions qui doivent �tre r�cup�r�es par l'application qui l'utilise...

Tant que je travaille avec la biblioth�que statique, il n'y a aucun probl�me, mais d�s que j'essaye de travailler avec la DLL, les exceptions restent bloqu�es au sein de celle-ci.

En effet, quand je cr�e un nouveau projet destin� � utiliser la dll, avec les bonnes caract�ristiques et que j'�cris le code tout simple

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
int main()
{
try
{
 AlgoTrace::exceptiontest();//fonction spécialement créée pour l'occasion
                            //destinée à tester les exceptions ;)
}
catch(std::exception &e)
{
    cout<<e.what();
}
    return 0;
}

plut�t que de r�cup�rer l'exception dans le catch, ainsi que je m'y serais attendu, j'obtiens le message de la mort:

terminate called after throwing a instance of 'AlgoTrace::AlgoException'
what(): une exception

mais qui est exactement le m�me message que si j'avais appel� la fonction en dehors de tout bloc try...catch.

Ce qui me rassure d�j�, c'est que l'exception est bien telle que je m'attendais � l'avoir... sauf que j'aurais cru la r�cup�rer dans mon application

Quelqu'un aurait il donc une id�e sur les param�tres � passer � Gcc (sous code::blocks) pour indiquer que les exceptions lanc�es par la DLL doivent en sortir

[Mat007]

Salut,

A mon avis il faut surtout ne pas laisser sortir d'exception d'une DLL, cf. C++, the real world, and link and binary compatibility.
Donc oui c'est p�nible, mais c'est apr�s tout logique si on veut vraiment garantir qu'une biblioth�que partag�e est vraiment utilisable en tant que telle.

En pratique tu devrais faire quelque chose comme try d�s l'entr�e dans la DLL puis positionnement d'un bon vieux last error dans le catch, puis un get last error + throw dans l'application juste apr�s chaque appel � la DLL...

MAT.

[M�dinoc]

Plut�t que de modifier ainsi une variable non-r�entrante, il serait peut-�tre plus pratique de retourner un HRESULT � la place (on peut y mettre toutes les erreurs Win32).
Ainsi, �a correspondrait au sch�ma HRESULT = Exception cher � COM et .Net...

[koala01]

En fait, et de mani�re � permettre de comprendre mon objectif:

L'id�e de cette biblioth�que est de fournir une "fa�ade" pour tout le code m�tier d'une application graphique.

L'application graphique permet � l'utilisateur d'ajouter, de modifier (supprimer) une s�rie d'�l�ments de diff�rentes sortes, mais les ajouts/modifications/suppressions doivent �tre "valid�s" par le code m�tier (la biblioth�que).

Au cas o� la validation d'une des modification �choue, c'est le code m�tier qui se charge de "faire le m�nage", et qui devrait id�alement permettre � l'application graphique de disposer des informations sur "ce qui n'a pas �t�".

Les �checs de validations sont g�r�s sur base de classes d�rivant de std::exception (et meme plus pr�cis�ment de std::runtime_error )

La difficult� suppl�mentaire vient du fait que, c'est mis dans le cahier des charges, la biblioth�que doit �tre ind�pendante et portable (sous r�serve �ventuelle de compilation, nous nous comprenons bien sur ce fait ).

L'id�e �tant de permettre d'utiliser cette biblioth�que avec diff�rentes interfaces graphiques et/ou sous diff�rents OS.

La "cerise sur le g�teau" aurait consist� � permettre la cr�ation d'une biblioth�que partag�e, mais il ne s'agit l� que d'un plus facultatif.

Cependant, je crains que les obligations de portabilit� ne m'autorisent pas � pr�voir un mappage sur HResult.

D'un autre c�t�, en y r�fl�chissant, j'adh�re tout � fait au probl�me soulev� sous la forme de

une exception survenue dans une dll ne devrait pas en sortir

D�s lors, peut �tre devrais-je envisager une solution alternative qui consisterait, pour les fonctions de fa�ade � consid�rer les exceptions lanc�es comme valeur de retour une fois qu'elles ont �t� g�r�es

Ainsi, mes fonctions de fa�ade pourraient prendre une forme proche de

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
 
const AlgoException fonction(/*...*/)
{
    try
    {
       /* tout ce qu'il faut, et qui est susceptible de faire foirer la validation*/
    }
    catch(const AlgoException& e)
    {
        /* gestion finale du ménage */
        return e;
    }
    return NoError();/* une variante de AlgoException qui représenterait...
                      * le fait que ca s'est bien passé
                      */
}

Est-ce que ce "d�tournement" de l'id�e des exceptions vous parait coh�rent

[Mat007]

Ca me parait toujours dangereux, par exemple si la d�claration et/ou la d�finition de std::runtime_error (et std::exception) diff�rent entre la compilation de la DLL et la compilation de l'application, �a va poser probl�me.
M�me s'ils ne diff�rent pas et qu'un m�me compilateur est utilis� de part et d'autre, pour peu qu'il y ait une certaine option de diff�rente, �a peut suffire pour avoir une repr�sentation en m�moire diff�rente...

En fait pour bien faire il faut m�me n'utiliser dans l'interface d'une DLL que des types de base dont on est s�rs qu'ils seront repr�sent�s de la m�me mani�re (comme int ou float).

Tu ne peux pas vraiment couper aux codes d'erreurs (12 et 42 sont mes pr�f�r�s ).

Enfin apr�s si ta biblioth�que n'est utilis�e que dans un cadre tr�s pr�cis que tu peux contr�ler, tu peux toujours imposer une certaine version d'un certain compilateur avec certaines options de compilation, ou demander � ce que l'ensemble soit toujours (re-)compil� comme un tout.
Mais du coup autant faire une biblioth�que statique...

MAT.

[koala01]

Enfin apr�s si ta biblioth�que n'est utilis�e que dans un cadre tr�s pr�cis que tu peux contr�ler, tu peux toujours imposer une certaine version d'un certain compilateur avec certaines options de compilation, ou demander � ce que l'ensemble soit toujours (re-)compil� comme un tout.
Mais du coup autant faire une biblioth�que statique...

MAT.

Ben, cette biblioth�que, m�me si elle a des chances, � terme, de se retrouver sous license GNU/GPL, n'a que peu de chances de servir pour autre chose que pour le projet pour lequel elle est d�velopp�e (� quelques variantes de compilateur, de biblioth�que graphique ou d'OS pr�s)...

De l� � demander � ce que la biblioth�que et l'application soient compil�es comme un tout, il n'y a en effet qu'un pas, et n'eut �t� le plaisir de fournir une dll, comme je l'ai dit, cela n'aurait �t� que la cerise sur le g�teau

J'en d�duis donc qu'il semble - a priori - impossible, et en tout cas d�conseill�, de faire remonter une exception d'une dll vers l'application qui l'utilise, et j'abandonne "tout simplement" l'id�e de fournir cette biblioth�que sous une autre forme que statique

Je remercie tout le monde pour le temps pass� � l'apport d'�l�ments de r�ponses, et consid�re le sujet comme cl�t

Maintenant, si certains avis veulent encore se faire connaitre, je reste preneur