Discussion :

[deubelte]

Bonjour

J'ai fait un programme qui provoque un access violation. C'est bien sur fait exprès. Je voudrais savoir la commande qui me permet de catcher une telle exception:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
int *e=new (int[3]);
 
	int *p=e;
	int *p1=e+1;
	int *p2=e-1300;
	try{
	*p2=4;
	}
	catch(...){
		cout<<"error";
	}

merci

[Invité]

Bonsoir,

De base, un signal ne déclenche mais d'exception.
Mais il est possible de surcharger le traitement par défaut comme ça :

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
17
18
19
20
21
22
#include <iostream>
#include <signal.h>
 
void catch_segv(int sig) {
  signal(SIGSEGV, catch_segv);
  throw strsignal(sig);
}
 
int main() {
  signal(SIGSEGV, catch_segv);
 
  int *e=new (int[3]);
  int *p=e;
  int *p1=e+1;
  int *p2=e-1300;
 
  try {
    *p2=4;
  } catch( char* msg ) {
    std::cout << "Catched: " << msg << std::endl;
  }
}

Nécessite une compilation avec l'option -fnon-call-exceptions.

[deubelte]

ok merci
mais ce n'est pas un exception C++, alors est-ce bien de la catcher?

[Invité]

Pourquoi est-ce que ça serait un risque ?
Qu'envisagez-vous de faire dans votre "catch" ?

[pyros]

Bonjour,

J'avais posé la même question mais je n'avais pas eu beaucoup de réponse :
http://www.developpez.net/forums/d10...p/#post5844773

Sous visual, tu peux spécifier l'option \EHa (prop. du projet->C/C++->Code Generation->Enable C++ Exception->Yes with SEH Exception) qui te throw une exception en cas de segfault, mais pas pour g++.

Le problème d'utiliser les signaux, c'est que tu n'es jamais sûr que quelqu'un d'autre n'utilise pas déjà le signal pour autre chose (on ne peut affecter qu'une seule action par signal si je me souviens bien).

Après, je dirais que d'essayer de cacher un segfault sous le tapis est dangereux car tu ne sais pas dans quel état se trouve la mémoire à ce moment là (même si dans 99% des cas elle n'a subit aucun dommage), et donc tu ne sais pas si ton programme pourra continuer normalement.

La meilleur chose à faire serait de trouver la source du problème, mais bon dans la vrai vie on peut pas toujours...

[koala01]

Salut,

Le gros problème, c'est que tu ne peux avoir strictement aucune idée de ce qui se trouve à e-1300, ni de l'usage qui en est fait...

Tu peux, tout aussi bien, te trouver au milieux d'une chaine de caractères à afficher (qui sera tronquée, dans le meilleur des cas), au beau milieu d'une fonction hyper sensible (qui, manque de bol, sera appelée si tu attrape le problème ) ou ... entre deux membres d'une structure personnelle.

Il t'est donc particulièrement difficile de déterminer le "moins mauvais" traitement à effectuer si tu arrive à attraper cette erreur

Ne crois tu pas que le mieux (en dehors de résoudre le problème de logique sous jascent, bien sur) serait dés lors de... laisser planter purement, simplement et brutalement l'application