Try/Catch

Signaler
Messages postés
11
Date d'inscription
dimanche 7 mai 2006
Statut
Membre
Dernière intervention
22 juin 2012
-
Messages postés
11
Date d'inscription
dimanche 7 mai 2006
Statut
Membre
Dernière intervention
22 juin 2012
-
Salut à tous !

Un problème tout bête mais j'ai passé la journée dessus (argg!!!!) alors je me décide à poster, ne trouvant aucune réponse...

Application MFC, mon application enregistre un fichier à partir d'informations contenues dans une base MySql. Voilà très grossièrement le schéma mis en place :

try
{
//Ouverture
CStdioFile file;
file open(monfichier.txt);

Boucle:
{
//Requete SQL qui récupère des informations

//Enregistrement des informations
file.WriteString(string_infos);
file.Flush();
}

file.Close();
}
catch(...)
{
//traitement de l'exception : affichage de l'erreur

}

Le fichier est en fait écrit sur une clé USB. La problématique est : "comment ne pas faire planter l'appli si on arrache la clé USB pendant l'export des informations ?"
J'ai mis en place le try/catch afin de récupérer toutes les exceptions, mais au lieu de ca mon appli crash si j'arrache la clé USB. L'appli ne rentre pas du tout dans le catch.

Une idée ?

D'avance merci à tous pour vos retours d'expérience !

Joël

8 réponses

Messages postés
3819
Date d'inscription
dimanche 12 décembre 2004
Statut
Modérateur
Dernière intervention
28 septembre 2020
113
Une exception ne sert pas à attraper une routine qui plante !
Un try catch n'est que pour attraper une exception levée volontairement.

Si tu veux attaper un plantage (communément appelé "segfault"), il te faut détecter le signal d'un segfault.
Sous Linux, c'est très simple à faire, grâce à la méthode sigaction de signal.h
Sous Windows, je ne sais pas, mais tu peux faire quelque recherche sur l'équivalent de sigaction sous Windows.

_____________________________________________
Historique de mes créations, et quelques articles:[ http://0217021.free.fr/portfolio
http://0217021.free.fr/portfolio]
Messages postés
792
Date d'inscription
mardi 8 juillet 2003
Statut
Membre
Dernière intervention
12 juillet 2019
8
Bonjour,
Si tu as une solution, je suis preneur aussi

louis
Messages postés
3819
Date d'inscription
dimanche 12 décembre 2004
Statut
Modérateur
Dernière intervention
28 septembre 2020
113
Il me semble que signal est aussi sous Windows.
Donc voici un petit exemple, à tester.

On pose un handler, et en cas de plantage, on revient au moment ou on a posé une "protection".
Je tiens tout de même à souligner le fait que c'est une très très mauvaise pratique, et qu'il vaut mieux investiguer sur l'origine de l'erreur plutôt que de la contourner !

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <string.h>
#include <setjmp.h>

static jmp_buf jump;

void handler()
{
  printf("Segmentation fault catched !\n");
  longjmp(jump, 1);
}

int main(void)
{
  printf("Program begin\n");

  signal(SIGSEGV, handler);
  if (!setjmp(jump) )
  {
    char* p = NULL;
    strcpy(p,"SEGFAULT, p is not allocated");
    printf("%s", p);
  }

  printf("Program is here\n");

  return 0;
}


_____________________________________________
Historique de mes créations, et quelques articles:[ http://0217021.free.fr/portfolio
http://0217021.free.fr/portfolio]
Messages postés
11
Date d'inscription
dimanche 7 mai 2006
Statut
Membre
Dernière intervention
22 juin 2012

Salut

Ben l'erreur est "connue" : la clé USB est arraché pendant la phase d'écriture, donc quand je fais mon WriteString et le Flush, une CFileException est levée.
Le reste du code est clean, ça marche impec. Mis à part cette histoire d'arrachage de clé....
Le problème serait donc de savoir comment récupérer systématiquement l'exception et que Windows ne termine pas l'application.
Intéressant ton exemple CptPingu, a essayer.

Joël

Ps: je précise que je l'appli tourne sur XP Embedded.
Messages postés
3819
Date d'inscription
dimanche 12 décembre 2004
Statut
Modérateur
Dernière intervention
28 septembre 2020
113
Dans ce cas, si une exception est levée, ça m'étonne que tu ne l'ai pas attraper avec un try catch all, du genre:
try
{
//...
}
catch(...)
{
}


Passe le sous un debugger, pour vérifier ce qui arrête ton programme.

_____________________________________________
Historique de mes créations, et quelques articles:[ http://0217021.free.fr/portfolio
http://0217021.free.fr/portfolio]
Messages postés
11
Date d'inscription
dimanche 7 mai 2006
Statut
Membre
Dernière intervention
22 juin 2012

Salut

Un mauvais signe (pour moi !) : une ancienne version du soft qui marchait très bien (y compris le coup de l'arrachage de la clé) ne marche plus. Après comparaison des codes sources, on avait bien aussi le try/catch(...), la seule différence se situe au niveau du traitement SQL (moins de data avec la version précédente du soft, donc moins de code dans le try{}).

Donc le coup du try/catch(...) marchait mais ne marche plus. Y aurait une config à faire au niveau de Windows pour récupérer toutes les exceptions ? (Base de registre ?)

Joël
Messages postés
3819
Date d'inscription
dimanche 12 décembre 2004
Statut
Modérateur
Dernière intervention
28 septembre 2020
113
Y aurait une config à faire au niveau de Windows pour récupérer toutes les exceptions ? (Base de registre ?)

Le "try ... catch" est un mécanisme du C++ et n'a absolument rien à voir avec l'OS.

En revanche, il est important de savoir pourquoi ton programme plante. Essaie de passer ton programme dans un débugger pour trouver l'origine du problème. (gdb, le debugger de visual, gdb embarqué dans QTCreator, ...)

Si ton programme est multi-plateforme (je suis sous Linux), je peux aussi jeter un coup d'oeil.

_____________________________________________
Historique de mes créations, et quelques articles:[ http://0217021.free.fr/portfolio
http://0217021.free.fr/portfolio]
Messages postés
11
Date d'inscription
dimanche 7 mai 2006
Statut
Membre
Dernière intervention
22 juin 2012

Salut CptPingu !

Merci de ton aide, mais c'est au final résolu. J'ai fais un peu de ménage dans le code, et déplacé le try/catch(...). Je ne vois pas la différence entre avant et après si ce n'est qu'il y a au final moins de code dans le try{}... (pas beaucoup moins).

En pensant configuration, je ne pensait pas au mécanisme du try/catch lui même, mais à la levée des exceptions, qui, sauf erreur, sont faites par l'OS. Si l'OS ne remonte pas une exception et termine l'application sans se poser de question, try/catch ou pas try/catch, le programme "plante". Non ?

Encore merci pour ton aide !

Joël

PS: Louis, si tu es toujours, là, essaie de déplacer ton try/catch(...)