Discussion :

[mokochan]

Bonjour,

je suis actuellement en train de développer un petit programme en c++, langage dont je n'ai pas trop l'habitude et j'ai quelques interrogations concernant les exceptions. J'ai écrit ce code:

Code :

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

1
2
3
4
5
6
7
8
try
{
    // Mon code ici
}
catch(exception e)
{
    cerr << "Failure: " << e.what() << endl;
}

En fait je ne sais pas trop comment savoir le type d'exceptions pouvant être levées par mon code, alors je met un "exception" qui si j'ai bien compris va "catcher" tout type d'exception.
Est-ce correct de faire de façon, et si non comment faire pour savoir quelle(s) exceptions gérer sans en oublier?
Merci d'avance pour votre aide!

[ternel]

En C++, on peut lever n'importe quoi.
std::exception est le type de base de toute exception levée par la bibliothèque standard.
Par contre, tu peux parfaitement écrire throw 42;, throw false;, throw "pas de chance"; ou encore throw std::map<int, int>();.

L'instruction qui permet d'attraper n'importe quoi est catch(...).
Bien sûr, "n'importe quoi" n'a aucun type défini, donc tu ne peux rien faire du tout de l'objet levé.
Tu ne pourras te servir que du fait qu'il a été levé.

Second conseil. Pour éviter des copies d'exception (ce qui est vital dans le cas d'un std::bad_alloc), il est recommandé d'attraper les exceptions par référence constante.

Code :

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

1
2
3
4
5
6
7
try {
    //du code
} catch (std::exception const& e) {
    arg_zut(e.what());
} catch (...) {
    paf();
}

Pour savoir quelles exceptions attraper, il faut avoir une documentation, ou lire le code .
C'est pour cela que des commentaires disant quelles exceptions sont levées sont utiles

[EpiTouille]

Salut

Donc en fait si tu fais

Code :

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

catch (exception e)

Tu ne vas pas catcher TOUTES les exceptions mais les exceptions qui héritent de std::exception. Il y a un moyen pour catcher toutes les exceptions c'est de faire

Code :

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

1
2
3
4
5
6
7
8
9
 
 
try
{
  // ton code;
}
catch (...)
{
}

Les "..." veulent bien dire toutes les exceptions.

Petite remarque en passant, quand tu fais

Code :

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

catch (exception e)

Tu fais une copie de l'exception e. En génréral on préfère un

Code :

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

catch (exception const& e)

Bon courage et bonne journée

EDIT: leternel tape plus vite que moi :'(

[ternel]

c'est l'entrainement

[foetus]

Pour savoir quelles exceptions attraper, il faut avoir une documentation, ou lire le code .
C'est pour cela que des commentaires disant quelles exceptions sont levées sont utiles

Il n'y a pas un truc en C++ du style

Code :

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

void /*or ...*/ my_method(/* ... */) throw std::bad_alloc /*, ...*/;

[ternel]

Plus maintenant.
En C++11 et suivant, il n'existe que nothrow() et nothrow(compile-time condition).

[mokochan]

C'est plus clair pour moi maintenant!
Je n'avais pas pensé à la copie d'exception.
Merci pour vos explications!

[Médinoc]

En plus, attraper une exception par valeur causerait du slicing (perte des données spécifiques à la classe dérivée).

[ternel]

Je sentais bien qu'il y avait une raison plus grave. Merci pour l'information!

[bacelar]

Et n'utilisez JAMAIS "catch(...)".
Cela ne présente que des inconvénients.
Ne catchez que ce que vous êtes en capacité de traiter. Et loguer, ce n'est pas traiter.

Laisser mourir un programme permet d'avoir un dump précis de ce qui c'est passé au moment de sa mort.

[ternel]

petit bémol, ne pas catch (...) sans relever.
Il est possible de relancer une exception avec throw.

Code :

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

1
2
3
4
5
6
try {
    throw 1;
} catch(...) {
    std::cerr << "une erreur est survenue pendant la phase surveillée" << std::endl;
    throw
}

[bacelar]

Pas de bémol, leternel.
Ce que tu proposes nique la stack-trace, change l'état de variables dans le dump, le tout pour un bénéfice totalement nulle.

[Médinoc]

Euh, normalement un throw sans argument n'est pas censé affecter la stack-trace, contrairement à un throw avec argument?

Et je ne sais pas debugger un dump; je ne sais même pas si le seul debugger que je sache utiliser (Visual) en est capable

[bacelar]

Et je ne sais pas debugger un dump; je ne sais même pas si le seul debugger que je sache utiliser (Visual) en est capable

https://msdn.microsoft.com/en-us/lib...or=-2147217396
Mais j'ai jamais essayé, j'utilise toujours WinDbg dans ces cas là.

Euh, normalement un throw sans argument n'est pas censé affecter la stack-trace, contrairement à un throw avec argument?

Je ne suis pas sûr dans le cas là, mais quand j'ai ce genre de code truffé de catch(...) pour le "blinder", le développeur ne fait pas de "sentiment" et parachève l'horreur avec un "traitement" générique à la con.
Mais quand on en est à lire le fichier de dump et pas à avoir le débuggeur qui nous insulte, c'est que les tests unitaires/d'intégration/etc... se sont fait transpercés et on reluque tout ce qui traine en mémoire et pas juste la stack-trace.

[Bousk]

Et je ne sais pas debugger un dump; je ne sais même pas si le seul debugger que je sache utiliser (Visual) en est capable

Il y arrive très bien, ça se fait très bien (heureusement!), il faut "juste" avoir les bons pdb

[JolyLoic]

Et n'utilisez JAMAIS "catch(...)".
Cela ne présente que des inconvénients.
Ne catchez que ce que vous êtes en capacité de traiter. Et loguer, ce n'est pas traiter.

Laisser mourir un programme permet d'avoir un dump précis de ce qui c'est passé au moment de sa mort.

Je ne suis pas vraiment d'accord. Il y a des contextes où ce que tu dis est valide, et d'autres où il vaut mieux s'arrêter gracieusement avec un joli log que d'avoir un dump. Et même si tu attrapes une exception, tu as moyen de générer un dump à l'endroit du lancement si tu le souhaites.

Après je suis d'accord qu'un programme ayant plein de catch(...) (ou de catch(exception &e)), c'est mauvais signe, mais en avoir quelques une, à des frontières très importante ne me choque pas du tout (par exemple un système de plug-in, tu peux vouloir que même en cas de chose incontrôlée dans le plug-in, le reste du programme continue à tourner, même si sa stabilité est compromise, ou alors à une frontière avec un autre langage qui ne sait pas propager des exceptions C++).

[ternel]

Comme d'habitude, on parle donc bien de "jamais" au sens informatique: "jamais sauf si vraiment il le faut". Comme avec une globale ou une macro