Discussion :

[alen]

Bonjour,
Je voudrais gérer de manière globale les erreurs de mon programme. Existe t'il des règles de bonne pratique?

[coyotte507]

généralement tu créés une ou plusieurs classes Erreur.

ensuite dans un bloc où il peut y avoir des erreurs:

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
 
try
{
  //bloc
  {
     .....
     {....
        if ( testerreur) // METTEZ un test à la place
        {
         Erreur er; // le nom de la classe erreur de son instance
         throw er;  //ca passe direct à la fin du bloc try et détruit les objets statiques dedans
         }
      }
    ... 
    }
}
 
catch (Erreur er) // nom de la classe erreur et son objet
{
  //gestion de l'erreur
}
catch(...) //Ca attrape tout ce qui n'a pas été attrapé par les autres catch comme erreur
{gestion de l'erreur}

Si tu veux plus de détails, recherche sur les exxceptions.

[Luc Hermitte]

Il y a tant à dire sur ce sujet.
En gros, rapidement.

J'utilise des assert (vive les core dump) pour détecter les erreurs de programmation.

J'aime bien les STATIC_CHECK (cf Modern C++ Design / Loki) -- boost a une macro similaire -- pour vérifier la consistance statique de mon code. Comme p.ex. que le nombre d'éléments dans un tableau correspond bien au nombre de valeurs possibles d'un type énuméré.

J'utilise des exceptions pour les erreurs liées au contexte d'exécution. Dans certains cas particuliers j'utilise des objets qui peuvent être dans un état invalide ou incomplet, et qui ne lêvent pas pour autant des exceptions -- cf les flux standard du C++.

Concernant les exceptions, il y a des petites choses à savoir :
- elles changent complètement la façon de gérer les ressources -- cf tout ce qui tourne autour de l'exception-safety que l'on (*) a enfin fini par comprendre, fais une recherche en particulier sur le RAII dans la FAQ. (et si je puis en rajouter une couche, le SESE (Single Entry - Single Exit -> recherche avancée!) n'est plus une fatalité vu que les exceptions le déstabilisent et que le RAII le remplace pour bien gérer les ressources)
Dans cette même famille, le test anti auto-affectation dans l'opérateur d'affectation est un contre-idiome.

- on doit les lever par valeur, et les attraper par référence (-> maladresse dans le code de coyotte507, maladresse qui se transforme en erreur dans le cas d'une hiérarchie d'exceptions)

- les spécifications d'exception dans les signatures des fonctions sont des attrape-nigauds. En effet, ce sont des assertions dynamiques non débrayables en mode release. Le compilateur ne vérifiant rien du tout à notre place.

- Grâce au RAII, il n'est pas nécessaire de truffer son code de blocs try-catch. On ne les utilise alors qu'au moment où l'on est capables de les interpréter et de les traiter -- parfois il s'agit de simple log vers l'utilisateur, ou des convertions depuis un type d'exception vers un autre

- J'aime bien avoir des classes RAIIsantes qui logguent en entrée et en sortie de portée

- Dans la FAQ C++lite, il y a une technique intéressante de dispatching d'exceptions

- il est parfois interessant de définir des classes qui tiennent plus du contrat que de l'interface : les fonctions publiques sont non virtuelles, elles vérifient les pré-, post-conditions et les invariants, et elles appellent au milieu une fonction privée/protégée virtuelle pure (pure dans la déclaration de la classe contrat).

- Matthew Wilson a pondu quelques artices repris dans un chapitre de son Imperfect C++ au sujet de la gestion des erreurs.

(*) je généralise peut-être un peu vite


J'ai certainement oublié des choses. J'ai probablement parlé de trucs qui vont te passer au dessus de la tête. Et j'ai très certainement été excessivement succinct.
Il y a tant à dire, qu'il est difficile de parler avec des généralités.

Autre bonne lecture : Coding Standards qui a quelques points à ce sujet, que j'ai d'ailleurs repris.

[loufoque]

Pour certains trucs particuliers, c'est-à-dire pour lesquels une erreur n'est pas une exception, il vaut mieux ne pas utiliser les exceptions.