Discussion :

[gilims]

Bonjour à tous,
Voici le problème: j'ai une classe, ICBond, qui prend dans son constructeur, 3 arguments, 2 adresses d'une autre classe ICAtom et un entier. Cependant, les 2 instances de classe ICAtom (qui sont des adresses) ne doivent pas être nulle. Donc un petit if pour vérifier, et si l'un des 2 est nul, je lance une exception. Le code marche parfaitement si les 2 atomes ont des adresses bien définis, mais si l'un d'entre eux à une adresse "nulle", j'ai un message d'erreur qui apparait à la fin de l'appel du constructeur, après avoir finis l'execution du catch et ce sans raison. Une idée ???

Message d'erreur :
Program received signal: “SIGABRT”.


Code ICBond.h

Code :

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

1
2
3
4
5
6
7
8
9
10
	class ICBond 
	{
	private:
		ICAtom* Atom1;
		ICAtom* Atom2;
		BondType  Type;
		bool Clear();
 
	public:
		ICBond(ICAtom* _Atom1, ICAtom* _Atom2, BondType _BType)throw (MolException);}

Code de la classe d'exception :

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
class MolException: public std::exception
{
public:
    MolException(int numero=0, const std::string& phrase="", int level=0) throw();
 
	virtual const char* what() const throw();
	int getLevel() const throw();
	int getNum() const throw();
 
    virtual ~MolException() throw()
    {}
 
private:
    int m_numero;               // Numéro de l'erreur.
    std::string m_phrase;       // Description de l'erreur.
    int m_level;               // Niveau de l'erreur: 
};

Le main :

Code :

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

1
2
3
4
5
6
7
 
int main (int argc, char * const argv[]) {
	ICAtom *Atm  = new ICNMole::ICAtom(1,1,1);
	ICAtom *Atm2 = NULL;//new ICNMole::ICAtom(2,2,2);
	ICBond *Bond = new ICNMole::ICBond(Atm,Atm2,ICNMole::Single);
 
}

Merci d'avance !!

[bruno_pages]

Bonjour

à tous,
...je lance une exception...

mais il n'y a personne pour la rattraper dans votre main, d'ou le problème

protégez donc vos allocations avec un try - catch

[gilims]

exact !!! La raison est simple: j'ai oublié de le mettre dans le post !! c'était déjà mis auparavant. Grossière erreur de ma part. Voici le constructeur :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
ICBond::ICBond(ICAtom* _Atom1, ICAtom* _Atom2, BondType _BType)throw (MolException)   
try
{
	if (_Atom1 == NULL)	  throw MolException(03001, "New Bond with a null atom",1);
	if (_Atom2 == NULL)   throw MolException(03001, "New Bond with a null atom",1);
	if (_Atom1 == _Atom2) throw MolException(03002, "New Bond between 1 identical atom",1);
	Atom1=_Atom1; Atom2=_Atom2; Type=_BType;
}
catch(MolException &e) {
	cerr<< e.what()<<endl;
}

[nikko34]

essaye ça :

Code :

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

1
2
3
4
5
6
7
8
 
ICBond::ICBond(ICAtom* _Atom1, ICAtom* _Atom2, BondType _BType)
{
	if (_Atom1 == NULL)	  throw MolException(03001, "New Bond with a null atom",1);
	if (_Atom2 == NULL)   throw MolException(03001, "New Bond with a null atom",1);
	if (_Atom1 == _Atom2) throw MolException(03002, "New Bond between 1 identical atom",1);
	Atom1=_Atom1; Atom2=_Atom2; Type=_BType;
}

Et dans ton main:

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
 
int main()
{
    try
    {
        ICBond bond( 0, 0, ICNMole::Single );
    }
    catch( const std::exception & e )
    {
         std::cout << e.what() << std::endl;
    } 
    catch( ... )
    {
        std::cout << "exception inconnue" << std::endl;
    }
}

[gilims]

Désolé pour le temps de latence.

En effet, cette façon de procédé marche. cependant, dans mon esprit (surement un peu fou je l'admets ), en mettant le try directement dans le constructeur, je voyais le moyen simple de ne pas avoir à le placer dans le main. Comme ca l'utilisateur qui déciderais de définir une nouvelle variable IBond aurait juste à rajouter vérifier si ca variable n'est pas un pointeur null plutot que de mettre un try catch à chaque fois qu'il fait une nouvelle IBond (sachant qu'il peux y en avoir quelques centaines de définis à chaque lancement du programme). Qu'en pensez vous ?

[bruno_pages]

quoi que vous fassiez dans le constructeur vous ne pourrez pas demander à celui-ci de retourner un pointeur nul, tout ce que vous pouvez faire c'est qu'il retourne une instance sur laquelle l'application d'une opération isValid retourne faux

[3DArchi]

Qu'en pensez vous ?

Que si ton utilisateur ne doit pas recevoir d'exception alors ton constructeur ne doit pas en lever. Mais tu dois, comme le dit Bruno, toujours retourner un objet valide si ton constructeur ne lève pas d'exception. Et/ou t'intéresser à la prog par contrat.

[koala01]

Salut,

Désolé pour le temps de latence.

En effet, cette façon de procédé marche. cependant, dans mon esprit (surement un peu fou je l'admets ), en mettant le try directement dans le constructeur, je voyais le moyen simple de ne pas avoir à le placer dans le main. Comme ca l'utilisateur qui déciderais de définir une nouvelle variable IBond aurait juste à rajouter vérifier si ca variable n'est pas un pointeur null plutot que de mettre un try catch à chaque fois qu'il fait une nouvelle IBond (sachant qu'il peux y en avoir quelques centaines de définis à chaque lancement du programme). Qu'en pensez vous ?

Le fait est que le principe même qui est suivi lorsqu'une exception est lancée dans un constructeur est d'éviter l'obtention d'un objet qui soit dans un état incohérent.

Or, bien souvent, si on détermine dans le constructeur qu'un objet se trouve dans un état incohérent, c'est, très certainement, parce qu'il y a eu "une couille dans le potage" avant que le constructeur ne soit appelé.

On ne peut donc envisager d'apporter une solution à ce problème que... en dehors du constructeur

Il faut aussi comprendre que le gros principe des exception est... de ne les récupérer que lorsqu'il est possible de les traiter en tout ou en partie.

Si le traitement de l'exception n'est que partiel, il faut donc envisager de... la faire remonter "plus haut" pour assurer un traitement complet (qui peut être le fait de décider de quitter l'application... plus ou moins correctement, parce qu'il est impossible d'apporter de meilleur solution).

L'affichage de l'erreur rencontrée ne peut en aucun cas être considéré comme une solution complète, car cela n'a qu'un effet "informatif" sur ce qui s'est passé.

Si tu ne relance pas l'exception dans le constructeur, tu obtiendra bel et bien un affichage de l'erreur provoquée, mais, comme l'exécution du programme continue "comme si de rien n'était" après être passé dans le catch, l'objet créé sera considéré comme... valide par le système, et cela même, alors que l'utilisateur saura qu'il n'en est rien.

Tu te doutes que ce n'est pas vraiment ce que tu veux, car l'utilisation d'un objet considéré comme valide par le système finira, tôt ou tard, par te "péter à la figure"