Discussion :

[vandamme]

Supposons que j'écrive ma propre exception qui dérive de std::exception et que je redéfinisse la fonction what() pour lui faire afficher un message particulier :

Code :

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

1
2
3
4
const char* what() const throw()
{
return "Mon exception";
}

Puisque cette fonction retourne un objet const char* alloué sur la pile, je voulais savoir à l'utilisation si la zone pointée par le pointeur retourné par what() sera toujours valide ?
Par exemple est - ce que

Code :

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

e.what()

pointe toujours sur une zone de mémoire valide sachant que l'on est sorti du scope de la fonction what() ?
Apparement, ça marche mais j'ai quand même un doute ...

[Luc Hermitte]

Je soupçonne (à vérifier), que la valdité du pointeur renvoyé par what() est liée directement à la portée de l'objet exception.

[Alp]

C'est ce qui parait hélas le plus logique.
vandamme > ça donne quoi ?

[vandamme]

Non, apparemment, même en dehors de la portée de l'objet exception, la zone pointée est toujours valide.
Je ne comprends pas bien pourquoi ....

[Luc Hermitte]

Parce que l'emplacement mémoire correspondant :
- provient d'une zone statique de constantes ?
- n'a pas encore été écrasée par d'autres allocations ? (c'est pas comme si les dandling pointers se repéraient au premier accès après libération)

[vandamme]

Est ce que ça veut dire (dans les 2 cas) que ce type de code est à éviter ?

[loufoque]

Tu renvoies un pointeur vers une chaîne littérale, qui est allouée dans une zone statique en lecture seule.
Ton code est donc parfaitement valide.

[vandamme]

D'accord, je pensais que la chaîne litérale était allouée sur la pile.
Comme par exemple si je faisais dans la fonction what() :

Code :

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

1
2
string s("ERREUR");
return s.c_str();

Ce qui, je pense n'est pas valide.

[Luc Hermitte]

* Pas bon dans tous les cas

Code :

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

1
2
3
4
char const* what() throw () {
    std::string s = ....;
    return s.c_str();
}

* Toujours bon

Code :

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

1
2
3
4
char const* what() throw () {
    char const* s = "....";
    return s;
}

* Bon ... ou pas.

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
struct TonException {
    .....
    char const* what() throw () {
        return m_s.c_str();
    }
private:
    std::string m_s;
};
 
 
.... 
const char * e = 0;
try { 
    throw TonException(.....);
} catch (TonException const& ex) {
    const char *s = ex.what(); // OK
    std::cerr << s << "\n"; // OK
    e = s; // OK
    std::cerr << e << "\n"; // OK
}
if (e) 
    std::cerr << e << "\n"; // PAS OK

Quant à stocker le ex.what() dans un pointeur externe à la portée courante, et faire un "throw;" pour relancer l'exception, là je ne suis plus sûr si on peut considérer que l'on attrapera le même object exception dans le gestionnaire du dessus.
Note: j'ai "simplifié" en attrapant par référence constante et pas par valeur.

(Enfin, c'est comme cela que je vois les choses)

[koala01]

Salut,

Il y a effectivement de fortes chances que

Code :

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

1
2
3
4
5
 
const char* what()
{
return "Erreur";
}

place la chaine erreur, qui est une constante litérale, dans la partie read-only de la mémoire de l'application, mais y a-t-il la moindre certitude que ce sera le cas

Le code

Code :

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

1
2
3
 
string s="Erreur"; /* ou string s("erreur");
return s.c_str();

me semble à moi aussi des plus suspect

Par contre, rien ne t'empeche de déclarer une variable membre à ta classe:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
class MonErreur/* :public qquechose */
{
    public:
        MonErreur(const std::string& error):
                 /* qquechose(...), */data_(error){}
        ~MonErreur() throw(){}
        const char* what() /* throw ()*/
        { return data_.c_str();}
    private:
        std::string data_;
};

De cette manière, le char* restera valable au moins jusqu'à destruction de l'objet de type MonErreur, et peut etre un peu apres, selon les aléas du besoin de la mémoire

[vandamme]

* Pas bon dans tous les cas

Code :

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

1
2
3
4
char const* what() throw () {
    std::string s = ....;
    return s.c_str();
}

* Toujours bon

Code :

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

1
2
3
4
char const* what() throw () {
    char const* s = "....";
    return s;
}

* Bon ... ou pas.

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
struct TonException {
    .....
    char const* what() throw () {
        return m_s.c_str();
    }
private:
    std::string m_s;
};
 
 
.... 
const char * e = 0;
try { 
    throw TonException(.....);
} catch (TonException const& ex) {
    const char *s = ex.what(); // OK
    std::cerr << s << "\n"; // OK
    e = s; // OK
    std::cerr << e << "\n"; // OK
}
if (e) 
    std::cerr << e << "\n"; // PAS OK

Quant à stocker le ex.what() dans un pointeur externe à la portée courante, et faire un "throw;" pour relancer l'exception, là je ne suis plus sûr si on peut considérer que l'on attrapera le même object exception dans le gestionnaire du dessus.
Note: j'ai "simplifié" en attrapant par référence constante et pas par valeur.

(Enfin, c'est comme cela que je vois les choses)

Merci pour tes réponses.
En principe c'est le même objet exception qui se propage, et c'est pourquoi il faut toujours l'attraper par référence pour garder l'objet polymorphe s'il l'est.

[vandamme]

Merci pour vos réponses.
C'est plus clair maintenant.