Discussion :

[vdumont]

Bonjour, je sais qu'un topic a recemment été ouvert sur le sujet des exceptions mais je trouvais qu'il était peu approrié à mon problème.


Je me fais une petite classe Utilitaire, qui comporte exemple une fonction pour convertur un paramètre T en std::string.


Est-ce que l'utilisation des exceptions est adéquates dans le contexte suivant?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
template <class T>
std::string Util::tostr(T value) 
{
    std::ostringstream oss;
    try {
        oss << value;
    }
    catch (const std::exception& error) {
        std::cerr << error.what() << std::endl;
    }
    return oss.str(); 
}

J'ai ajouter ce traitement d'exception car supposons que le programmeur (lorsque je ne serai plus en stage ici) utilise Util::tostr pour tenter de convertir quelque chose en string (un objet X par exemple) et que cela est impossible, cela lui lance une exception.


Est-ce adéquat? Merci

[Swoög]

Salut !

Alors, non ce n'est pas adéquate, pour la simple est unique raison que la déterminisation des templates (le fait de remplacer les types génériques par des vrais types) se fait à la compilation, et non pas à l'exécution...

donc il te sera (normalement) signalé à la compilation que l'opérateur

Code :

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

ostringstream << T

n'existe pas.
de plus, même en supposant que ça fonctionne, ici, avec ton catch, l'exception ne sortira de toutes façon jamais de la fonction...donc le programmeur ne la verra pas...

[bigboomshakala]

J'ai ajouter ce traitement d'exception car supposons que le programmeur (lorsque je ne serai plus en stage ici) utilise Util::tostr pour tenter de convertir quelque chose en string (un objet X par exemple) et que cela est impossible, cela lui lance une exception.

si tu passe un objet pour lequel il n'y a pas de conversion implicite vers un type supporté par l'opérateur << l'erreur est détectée à la compilation.

[vdumont]

Ok merci


Mais Swoog, si j'ai exemple:

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
23
24
25
26
27
28
29
30
class Util 
{
  public:
  Util();
  ~Util();
 
  template <class T>
  static std::string tostr(T);      // Convertir en string
 
  template <class T>                // Convertir en entier
  static int toint(T);
}; 
 
template <class T>
std::string Util::tostr(T value) 
{
    std::ostringstream oss;
    oss << value;
    return oss.str(); 
}
 
template <class T>
int Util::toint(T value) 
{
    std::istringstream iss(value);
   int integer;
    iss >> integer;
    return integer;
}

NB: La déclaration et l'implémentation sont tout 2 dans un fichier .h dans ce cas ci.


Ca fonctionne quand je l'appel dans mon code en faisant Util::toint("blabla");
Exemple

Code :

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

1
2
todraw.insert(std::make_pair(Util::toint(nomaillage),childvalue));

Je comprend pas trop le problème des templates que tu essaies de m'expliquer. Merci!

[Swoög]

essaie ce code :

Code :

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

1
2
3
4
class NCLASS_TEST { };
[...]
NCLASS_TEST test;
std::cout << Util<NCLASS_TEST>::tostr(test) <<endl;

tu devrais comprendre ce que je veux te dire

[vdumont]

Et bien ca ne fonctionnera pas car l'opérateur << ne sera pas capable de faire la conversion implicite d'un objet NCLASS_TEST???

Mais de la façon que je l'utilise est-ce que c'est mauvais?

Et pourquoi est-ce que tu utilises Util<NCLASS_TEST> toint(test);

En passant test en paramètre le T est donc considéré comme un type NCLASS_TEST non? Si oui pourquoi indiquez NCLASS_TEST entre < > ?

[Swoög]

Et pourquoi est-ce que tu utilises Util<NCLASS_TEST> toint(test);

En passant test en paramètre le T est donc considéré comme un type NCLASS_TEST non? Si oui pourquoi indiquez NCLASS_TEST entre < > ?

Désolé, j'ai cru que le template était sur la classe entière, il ne faut pas le mettre en effet, j'ai confondu

[Laurent Gomila]

Ce qu'il veut dire, c'est que le seul cas[*] où une injection dans un flux peut échouer, c'est si aucun opérateur << n'est défini entre le type en question et un ostream. Mais ça ce sera géré à la compilation, pas à l'exécution.

Pour l'extraction par contre (>>), tout un tas d'erreurs peuvent survenir, et là il faudra effectivement une bonne gestion des erreurs.

Par ailleurs, que je sache, les flux ne lancent jamais d'exception, ils gèrent les erreurs via des flags ; pour gérer les erreurs il faut donc tester le flux et non pas tenter d'attraper des exceptions.

[*] Il y a sûrement des cas où un flux de sortie provoque une erreur, mais ça doit relever du pinaillage

[vdumont]

Merci pour la réponse Laurent.

Je devrais donc faire quelque chose du genre if (iss >> integer)



Autre chose que je me demandais, dans le cas ou il y a eu un échec, quel genre de valeurs je devrais retourné pour signaler qu'il y a eu un problème? Le classique -1 serait-il approprié?

[Swoög]

Autre chose que je me demandais, dans le cas ou il y a eu un échec, quel genre de valeurs je devrais retourné pour signaler qu'il y a eu un problème? Le classique -1 serait-il approprié?

Dans ce cas par exemple, la lever d'une exception serait apropriée, c'est le plus sûr des messages d'erreur ^^