Discussion :

[duplo]

Bonjour a tous,

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

Code :

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

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 :

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

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 :

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

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 :

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

[Genjin]

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.

[Alp]

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.

[koala01]

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

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 :

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

1
2
3
4
5
 
class monerreur:std::exception
{
/*...*/
};

ou de

Code :

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

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 :

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

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 :

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

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

[Alp]

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 :

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

using namespace std;

se glissera dans le code

[Bakura]

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.