Discussion :

[LeonCosnyd]

Bonjour,

J'aimerais avoir vos conseils quant à la gestion des exceptions dans qtCreator.

Je connais le fonctionnement "basique" des try/throw/catch mais mon interrogation se trouve à la question suivante :

Est-il possible d'initialiser le projet avec un code qui gérerait toutes les exceptions rencontrées au cours de l'utilisation du logiciel ?


En gros je voudrais dire au tout début du programme que s'il y a une exception je veux afficher un message avec le détail de l'exception.

Est-ce possible ou est-il obligatoire de redéclarer le code d'exception a chaque traitement ?

Merci d'avance.

[dalfab]

Bonjour,

Si on place un block try/catch dans la fonction main() toute exception se retrouvera 'catchée', mais attention comme on est remonté au niveau main() l'application ne pourra au mieux que s'arrêter rapidement après.
En Qt, cela pourrait être

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( int argc , char** argv ) {
    QApplication app( argc , argv );
    try {
        app.exec();
    }
    catch ( QException& e ) {
    }
    catch ( std::exception& e ) {
    }
    catch ( ... ) {
        texte = "inconnue";
    }
    if ( !texte.IsEmpty() )
        QMessageBox::critical( 0, "exception", texte );
    return 0;
}

[LeonCosnyd]

Bonjour et merci pour cette réponse.

J'en déduit donc qu'un try catch dans le main capte toutes les exceptions du programme (même celle qui sont d'un niveau plus bas).

Par contre est-il possible d'avoir un message clair qui nous indiquerait la cause de l'exception ? Par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
int main( int argc , char** argv ) {
    QApplication app( argc , argv );
    try {
        app.exec();
    }
    catch ( ... ) {
        texte = UneFonctionQuiDonneLeDetailDeLexception;
    }
    if ( !texte.IsEmpty() )
        QMessageBox::critical( 0, "exception", texte );
    return 0;
}

[dalfab]

Le C++ est un langage fortement typé, dans le cas ... on ne peut pas grand chose.
Heureusement les exceptions dérivent normalement de std::exception
on peut alors faire catch ( std::exception &e ) { texte = e.what(); }

[Daïmanu]

Bonjour.

J'en déduit donc qu'un try catch dans le main capte toutes les exceptions du programme (même celle qui sont d'un niveau plus bas).

Si les fonctions appelées ne la capture pas, l’exception remonte en effet au main. Là, si un catch dont le type correspond existe, l'exception est arrêtée et traitée. Sinon le programme plante car rien n'a arrêté l’exception.

Par contre est-il possible d'avoir un message clair qui nous indiquerait la cause de l'exception ? Par exemple :

Tu peux aussi créer tes propres exceptions pour plus de sémantique :

Code :

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

1
2
3
4
5
#include <exception>
class ErreurPersonnalisee : public std::exception {
    public:
        ErreurPersonnalisee() : exception("Message personnalise") {}
};

[koala01]

Salut,

De manière générale, il est important de comprendre ce qu représente une exception... C'est la seule manière d'arriver à comprendre ce que l'on peut faire pour les traiter

Une exception correspond à une situation d'erreur dans laquelle l'application se trouve à un moment donné sans qu'on ne puisse considérer que c'est la faute du développeur. Allez, un exemple tout bête... :

Mettons que tu veuilles contacter un serveur distant. Manque de bol, il entre justement en maintenance lorsque tu essaye de le contacter.

1. quoi que tu aies voulu demander au serveur distant, tu pourras te "brosser" pour avoir une réponse, vu qu'il est HS
2. on ne peut pas dire que c'est la faute du développeur de l'application
3. peut-être peux tu décider d'attendre "quelques temps" avant de réessayer de le contacter

Hé bien, là, nous sommes clairement dans le cas où l'utilisation d'une exception peut s'avérer utile :
Quand tu te rends compte que tu n'arrive pas à connecter le serveur distant, tu sais que tu seras dans l'impossibilité complète de continuer à travailler, vu que tu n'auras jamais sa réponse. Tu vas donc lancer une exception qui indiquera "attention les gars, j'ai pas su contacter le serveur distant, je n'ai donc pas su faire mon job".

Cette exception est destinée à "remonter la pile d'appels" jusqu'à ce qu'on arrive (peut être!!!) au niveau d'une fonction qui pourrait décider de se dire "bon, d'accord, le serveur ne fonctionnait pas... je vais donc attendre cinq minutes, et je vais relancer le processus qui essayera de le contacter".

Et, dans le pire des cas, hé bien on remonte jusqu'au "tout début" de l'application. On remonte au niveau de la fonction principale. Le problème à ce moment, c'est qu'on a souvent perdu pas mal d'autres informations et que l'on n'a plus grand chose comme possibilité pour arriver à "relancer la machine". A ce moment là, le mieux est peut être "tout simplement" de laisser planter l'application proprement (après, c'est toujours plus sympa , avoir affiché un message d'excuse à l'utilisateur).

Maintenant, entre le moment où l'erreur survient (entre la fonction qui essaye de contacter le serveur distant) et le moment où il est possible d'apporter une solution complète au problème, il se peut que l'on puisse (ou non, il faut voir quel est le problème, quelles sont surtout les solutions à apporter et surtout où ces solutions devront être mises en place) apporter quelque morceaux de la solution à différents endroits dans le code.

L'idée sera alors que, chaque fois qu'il est possible d'apporter une partie de la solution à un endroit donné, nous nous donnerons l'occasion d'attraper l'exception lancée afin, justement, d'apporter ce "petit bout" de la solution