Discussion :

[Aurelien.Regat-Barrel]

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
24
25
26
 
class Object
{
// ancien code
 
public:
    static Object* New() // renvoie NULL en cas d'échec
    {
        try
        {
            return new Object;
        }
        catch (... )
        {
            return 0;
        }
    }
};
 
// ...
 
Object *obj = Object::New();
if ( obj == NULL )
{
    // ...
}

personnellement je désaprouve, mais c'est comme tu veux.

[xxiemeciel]

ce qui m'oblige encore une fois a changer tout les appels existant a new pour mon objet.

Donc retour a l'idée de depart , prevoir un comportement de l'objet dans le cas de l'Erreur.

XXiemeciel

[Aurelien.Regat-Barrel]

J'ai compris que tu as la classe Object, qui est utilisée par beaucoup de code.
Toi, tu veux l'utiliser sans les exceptions.
Donc on te propose une solution où, sans toucher au code existant, tu peux rajouter une fonction que tu utilises comme tu le veux toi, et l'ancien code continue à être basé sur les exceptions.
Je ne comprends pas pourquoi tu veux modifier tous les appels à new.

Sinon, effectivement, si tu peux repenser à zéro ta gestion des erreurs et avoir un comportement cohérent, c'est mieux.
Une exception, normalement, tu la laisse filer parce que si elle est levée, l'appelant ne peux rien faire pour corriger cela.
Typiquement, il manque de la mémoire. Ah ben, tu obtiens un pointeur nul, et après tu fais quoi ? Tu renvoies à ton tour une erreur à l'appelant, qui lui ne sait pas quoi faire, et renvoie à son tour jusqu'à ce que quelque part un bout de code s'occupe de gérer le manque de mémoire... c'est exactement le principe des exceptions, sauf que c'est transparent.
Maintenant si dans un objet Fichier, c'est l'exception FileNotFound qui est levée quand on ouvre un fichier, ça devient trop lourd, puisque c'est typiquement l'appelant qui sait le mieux réagir à un échec d'ouverture du fichier.
Les exception, c'est juste un mécanisme de transport d'une information d'erreur. Il faut te poser la question du destinataire de chaque erreur. Si c'est l'appelant, l'exception sera un mauvais choix. Sinon elle peut être justifiée.

[xxiemeciel]

Le code sur lequelle je travail existe pour certaines partie depuis plus de 15 anset sont en C. Le systeme n'utilisait pas les exceptions meme pour le code C++ qui est venu apres.

Moi je suis chargé de tester certaines classe et de resoudre les problemes si j'en trouve. J'ai decouvert une faille dans un objet, si on lui passe un mauvais parametre de construction il se construit quand meme et a un mauvais comportement ce qui peut etre tres dangereux.

ma premiere idée a été de jeter une exception lorsque le parametre etait mauvais (la compagnie a rajouter un systeme d'exception il y a 2 mois seulement ...)

mais la je me suis rendu compte que jeter une exception dans un constructeur pouvait etre problematique, donc, comme je n'allais pas reprendre les 2 millions de ligne de code pour rajouter try/cacth a chaque appel de new sur mon objet j'ai essayé de trouver une autre solution.

Est-ce plus clair maintenant ?

XXiemeciel

[Aurelien.Regat-Barrel]

Le problème est donc dans le choix des exceptions comme mécanisme de signalement d'erreur. Tu es en contradiction avec toi même:
- tu veux signaler une erreur avec une exception
- tu ne veux pas traiter cette erreur via les exceptions
tu peux alors maintenir un état "invalide" dans ton objet, comme le fait ifstream quand l'ouverture du fichier échoue:

Code :

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

1
2
3
4
5
6
 
std::ifstream fichier( "toto.txt" );
if ( !fichier ) // ou fonction type isValid()
{
    // erreur
}

si c'est bien l'appelant qui peut y faire quelque chose. Sinon, faut laisser filer l'exception. Mais note que dans les 2 cas, il faudra reprendre tout le code existant...
Note aussi que par défaut le test pour NULL sur le retour de new est toujours faux, sauf avec de vieux compilateurs (VC++ 6). Les compilateurs récent renvoient un objet créé, ou lèvent une exception, mais jamais NULL. C'est peut être un point qui peut justifier la reprise de tout votre code.

[xxiemeciel]

c'est pour cela que je dit que je ne vais PAS utiliser les exceptions et faire un comportement specifique au cas a probleme

XXiemeciel