à propos de "l'idiome GetLastError"
Bonjour,
j'ai commencé le dev en entreprise avec la MFC. J'ai mis longtemps à m'en remettre et ré-apprendre à coder correctement en c++, mais j'en garde des séquelles. Notemment cet "idiome du GetLastError" que j'utilise toujours, et même de plus en plus fréquemment.
Ce que j'entends par "idiome du GetLastError", c'est une chaîne de carractère en membre privé d'une classe, avec un accesseur, dans laquelle on stocke un message d'erreur lorsqu'une erreur est survenue lors d'un traitement au sein de cette classe. L'idée est qu'ainsi les fonctions membres de cette classe ne renvoient qu'un booléen (true si ok, false si une erreur est survenue), et lorsque l'utilisateur de cette classe veut savoir ce qu'il s'est passé, il appelle cette fonction GetLastError().
Un peu de code pour illustrer:
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| class MaClasse
{
public:
bool FaitQuelqueChose(); // return true si ok, false si erreur
inline const std::string & GetLastError() const { return last_error_; }
private:
mutable std::string last_error_; //mutable car on veut pouvoir gérer l'erreur même dans les fonctions constantes
};
int main()
{
MaClasse ma_classe;
if ( !ma_classe.FaitQuelqueChose() )
{
// traitement de l'erreur en utilisant ma_classe.GetLastError();
}
//...
} |
Le truc c'est que je vois beaucoup d'avantages, mais pas d'inconvénients. Les avantages sont:
. indépendance de cette classe avec le système de log de l'application (qui peut être complexe parfois)
. simplification de l'interface: les fonctions susceptibles de générer des erreurs ne renvoient qu'un simple booleen.
. avec cette technique, pas besoin de remonter les exceptions.
. simplification d'utilisation de la classe : l'utilisateur de cette classe ne s'occupe des erreurs que s'il en a besoin.
Mais comme je ne vois pas beaucoup d'utilisation de cet idiome (à part dans la MFC), je suppose qu'il doit y avoir de nombreux inconvénients. Savez-vous quels sont-ils?
