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