Migration vs2003 -> vs2005: Catch exceptions

Salut,

J'ai migre une application de Visual Studio 2003 vers Visual Studio 2005.
Je suis confronte a un probleme avec le catch d'exceptions.

Le programme catche bien toutes les exceptions / crash sous VS2003, par contre sous 2005 toutes les exceptions ne sont pas catchees.

exemple de code qui catch le crash en 2003 et pas en 2005 :

Code:

---

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

void myfunc2() { try { vector<string> a = Split("rrrr", "a", false); a[20] = 's'; } catch (...) { printf("CRASH!!\n"); } }

---

J'ai fait le tour des proprietes du vcproj mais sans succes. (CLR, SEH...)

Pouvez vous m'aidez ?
Je dois a tout prix etre en mesure de catcher tout type de crash possible puisque mon programme utilise des DLL fournies par des utilisateurs, donc on ne peut pas les considerees fiables a 100% et ca ne doit pas mettre en peril l'application.

Merci d'avance !

Ton exemple met en péril la pile. Si elle est corrompue le catch ne fonctionnera pas. Si ça fonctionne en vs2003, je pense que c'est un coup de bol.

Citation:

---

Envoyé par camboui

Ton exemple met en péril la pile. Si elle est corrompue le catch ne fonctionnera pas. Si ça fonctionne en vs2003, je pense que c'est un coup de bol.

---

Peux tu expliquer plus en details ?


En tout cas il semble que visual 2005 ne gere pas du tout de la meme facon les exceptions et j'ai du mal a arriver a tout catcher (je suis bien conscient que dans certains cas ca peu corrompre la memoire et mettre en peril tout le contexte d'execution).

Remplace ta ligne
a[20] = 's';
par
a.at(20) = 's';
pour voir...

Oui en effet utiliser .at() fonctionne, l'erreur est catchee.

Sauf que dans mon cas je ne sais pas comment vont coder mes utilisateurs et je souhaite dans 99% des cas etre en mesure de catcher l'erreur.

Quelle difference y a-t-il entre VS2003 et VS2005 pour que l'un le gere tres bien et pas l'autre ?
N'y a-t-il pas moyen de configurer mon projet pour que ca foncitonne de la meme facon ?

L'opérateur [] du vector n'est pas sensé tester la validité de l'index, mais "at" si.
Cela dit, souvent l'opérateur test quand même la validé de l'index en mode debug.
Donc les explications que je vois sont:
- Ton projet VS2003 est en debug mais pas ton projet VS2005(sans oublier le #define _DEBUG et NDEBUG qu'utilise peut-etre ta STL). Dans ce cas il suffit de bien configurer ton projet.
- VS2003 test en debug, et pas VS2005. Dans ce cas(mais je serais surpris), il doit être possible de modifier un tout petit peut ta STL, et de rajouter ce test en mode debug.(J'ai eu exactement ce problème sous borland).

Debug ou release ca fait la meme chose :(

Ce ne serait pas une histoire CLR / SEH qui ne fonctionnerait pas de la meme facon sous 2003 et 2005 ?

Avez-vous les même options entre VS2003 et VS2005, en particulier la gestion asynchrone des exceptions ?

Je ne m'étalerais pas sur le fait qu'un "catch ..." est tout sauf une bonne idée.

Utilisez une architecture de plug-Ins, avec des contextes mémoire et de pile les plus cloisonnés possible grâce, entre autre, aux threads.

Oui les options sont les memes entre 2003 et 2005.

Pour ce qui est de la gestion multi modules elle est faites par thread. Mais a ma connaissance les thread etant crees au sein du meme processus, la memoire est partagee pour tous les thread.

Un thread qui va faire un access violation fait planter l'application complete et pas uniquement son thread.

Par défaut, à partir de Visual 2005, un catch(...) attrape les exceptions C++, mais pas les exceptions SEH ordinaires (sans doute pour des raisons de conformité au standard C++).
Mais ça peut se changer.

Citation:

---

Envoyé par Médinoc

Par défaut, à partir de Visual 2005, un catch(...) attrape les exceptions C++, mais pas les exceptions SEH ordinaires (sans doute pour des raisons de conformité au standard C++).
Mais ça peut se changer.

---

Oui je suis deja en /EHa

Je rajoute que catcher une access violation dans le même process n'est généralement pas une bonne idée, car ça montre que tu as déjà de la mémoire corrompue quelque part.

Si vous n'avez pas confiance dans le code des Plug-Ins et être blindé contre des accès violations (je trouve cela un peu excessif, surtout si votre application se ferme en bonne ordre avec des finally).
Plusieurs solutions :
En .NET, faire des Plug-Ins des assembly "safe" chargé dans des AppDomains indépendant de celui de l'application.
En COM, faire des Plug-Ins soit des composant out-of-process, soit des composant chargé via du surugate.
Plus old school, en utilisant des processes indépendant en client/serveur par exemple avec un médian de communication quelconque.

Mais aucune n'utilise un catch(...) complètement dérisoire face à une dll pouvant tous faire. C'est comme brandir une feuille de papier face un à missile balistique multi-ogive de plusieurs centaines de mégatonnes chacune