[exception] j'en ais une mais pas la bonne

Bonjour a tous,

j'ais crée une petite plasse d'exception que voila :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

class exception{ public: virtual const char* what()const{ return "erreur signalée par l'exception générique du dup"; } };   class except_indice_invalide{ public: virtual const char* what()const{ return "erreur indice invalide"; } };

---

que j'appel ici :

Code:

---

1 2 3 4 5 6

template <class T> T& vecteur<T>::operator[] (unsigned int _nb)throw(){ if(_nb>=this->_taille) throw except_indice_invalide(); return this->tab[_nb]; }

---

et je recupere mon exception comme sa :

Code:

---

1 2 3 4 5 6

vecteur<T> vect(4);try{ vect[44]; } catch(const except_indice_invalide& _e){ cerr << _e.what() << endl; }

---

a l'execution, j'obient un message qui est apparament une exception :

Citation:

---

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

---

mais qui ne contient pas le message que je veux ...

pouriez vous m'eclerer sur la provenance de ce message?
comment faire pour obtenir mon exception et non celle ci?

merci d'avance

Le mot clef throw() sur ton opérateur indique qu'il ne lance jamais d'exception. Ainsi lorsque une exception survient à l'exécution dans ton opérateur le comportement standard est de terminer l'exécution. Il faut utiliser throw(...) ou throw(except_indice_invalide) pour indiquer les exception que peut lancer ton operateur.

Autre conseil : change le nom de ta classe, car si tu as un "using namespace std" quelquepart, il va y avoir une collision de noms.

Salut,

Bon, d'abord et avant tout, pourquoi ne pas utiliser les exceptions fournies par la STL elle-meme, ou, à défaut, faire dériver les tiennes de l'une d'elles:question:

Si tu inclue le fichier <stdexcept>, tu disposes en effet de

• std::exception
  
  • runtime_error
    
    • range_error
    • underflow
    • overflow
  • logic_error
    • domain_error
    • invalid_argument
    • out_of_range
    • length_error

qui sont autant d'exception dores et déjà définies...

Rien ne t'empeche donc de dériver tes propres exceptions sous une forme proche de

Code:

---

1 2 3 4 5

class monerreur:std::exception { /*...*/ };

---

ou de

Code:

---

1 2 3 4 5

class monerreur:std::runtime_error {   };

---

(ou de n'importe quelle classe d'exception d'ailleurs)

Ensuite, ainsi que l'a fait remarquer Genjin, quand tu déclare quelque chose avec le mot cle throw
(T& vecteur<T>::operator[] (unsigned int _nb)throw(){/*...*/} ), seules les exceptions qui sont mises entre les parentheses qui suivent le throw sont susceptibles d'etre lancées par la fonction.

Ne rien mettre revient à empecher la fonction de lancer la moindre exception, ce qui fait que l'on obtient, si une exception survient, un "unexpected error" (erreur inattendue)... qu'il devient, à peu pres impossible de gérer...

Finalement, il n'y a vraiment que pour une question de compatibilité avec les exceptions de la STL qu'il faille envisager de prévoir le destructeur et la méthode what sous la forme de

Code:

---

1 2 3

~tonerreur() throw(){} const char* what() throw(){/* ...*/}

---

Pour toute autre fonction, autant éviter de placer le mot cle throw dans le prototype ;)

Enfin, et ce n'est qu'un détail, il faut savoir que les std::vector disposent d'une méthodes qui vérifie justement si l'indice auquel on essaie d'accéder est correct, et qui lance une exception de type std::out_of_range (je crois): la fonction at(size_t index) ;)

Ta surcharge de l'opérateur pourrais donc devenir

Code:

---

1 2 3 4

T& vecteur<T>::operator[] (unsigned int _nb){ return at(_nb);/* exception automatiquement lancée si _nb>=size() ;) */ }

---

Il est en général bien plus pratique de faire hériter ses exceptions de celles standard, qui fournissent une hiérarchie correcte si l'on veut venir emboiter sa propre hiérarchie d'exceptions.
Par contre, encore une fois, évite les noms déjà utilisés dans l'espace de nom standard pour ne pas avoir de conflits de noms dès lors qu'un

Code:

---

using namespace std;

---

se glissera dans le code

J'ai une question en effet à propos de ces excpetions, pourquoi tout le monde crée ces propres classes alors que celles fournies en standard semble couvrir quand même pas mal de situations. Surtout qu'une classe exception c'est qu'une chaîne de caracètre avec une fonction what, je vois pas trop l'interêt de créer ses propres classes.

En général l'exception stocke des informations sur le contexte qui a déclenché l'erreur, et parfois un simple message ne suffit pas, donc dans ce cas il faut créer une exception perso.

On peut aussi créer une exception perso juste pour avoir un constructeur qui prend les paramètres qui vont bien, et qui construit le message d'erreur tout seul.

Encore une autre utilité, c'est lorsque l'on veut filtrer de manière précise les exceptions. Par exemple si je veux gérer toutes les exceptions que le module audio de mon moteur de jeu va lancer, je crée une classe AudioException et je pourrai n'intercepter que ces exceptions.

tout d'abord merci a tous pour vos réponses rapides et efficaces.

en ce qui concerne les noms déjà utilisés dans la stl c'est une erreur de ma part.

pour tous ceux qui le demande je n'utilise pas lesexceptions standart d la stl parce que je suis en train de refaire les classes de la stl (en plus léger et en français ^^) dans le but de comprendre leur fonctionnement complet donc je m'efforce de réutiliser le moins possible de code qui n'est pas de moi.

merci encore pour vos réponses

Citation:

---

Envoyé par duplo

je suis en train de refaire les classes de la stl (en plus léger et en français ^^)

---

Rien que ça :aie: ! Bon courage pour cette immense entreprise :king:.

Citation:

---

Envoyé par Bakura

Rien que ça :aie: ! Bon courage pour cette immense entreprise :king:.

---

c'est une maniere de voire les choses :mrgreen: je voulais dire ( si je me suis mal exprimé ) reprendre les pricipales libraires tel vector, list, string et les recodent, cela est trés instrucif et aide tout de même pas mal a comprendre le fonctionnement interne de ces librairies.