Comment puis-je vérifier l'échec du constructeur () sans utiliser d'exceptions?

Pourquoi les exceptions ne doivent pas être utilisées? La meilleure façon de retourner l'erreur du constructeur est de lancer l'exception. L'objet qui est construit à tort ne doit pas utiliser et lancer une exception garantit que.

Vous pouvez faire référence à cette FAQ: Comment Puis-je gérer un constructeur qui échoue?

Deux suggestions:

• L'ancienne mode SETJMP / LONDJMP ()
• une variable mondiale errno sim

Il n'y a pas de bon moyen; C'est l'une des principales raisons pour lesquelles ils ont été ajoutés à la langue en premier lieu. Sans exceptions non plus:

1. effectuer une sorte d'affirmation () dans le constructeur pour arrêter l'exécution; impossible à ignorer, mais impossible à récupérer de.
2. Faites votre construction réelle dans une fonction init.
3. ... ou gardez-le dans le constructeur, mais définissez un drapeau "mauvais".

   Personnellement, je pense que 2 est strictement meilleur que 3, car il n'augmente pas la taille de la classe et le rend plus visible lorsque la fonction "Vérification" n'est pas appelée. Il y a des raisons d'entendre citée, comme si vous pouviez accéder aux fonctions virtuelles, mais j'ai toujours considéré cela pour être assez faible.

Si vous ne voulez pas utiliser des exceptions, il existe deux façons de laisser l'appelant savoir si le constructeur a réussi ou non:

1. Le constructeur prend une référence / pointeur sur un paramètre qui communiquera le statut d'erreur à l'appelant.
2. La classe implémente une méthode qui retournera l'état d'erreur du constructeur. L'appelant sera responsable de la vérification de cette méthode.

   Si vous accédez à l'une de ces techniques, assurez-vous que votre destructeur peut gérer une instance dans laquelle le constructeur a échoué.

Ceci est laid et je ne le recommande pas vraiment, mais em> si vous n'êtes pas autorisé à lancer dans le constructeur, vous pouvez avoir un constructeur muet et une fonction init:

class Foo
{
private:
    AnotherClass a;
public:
    Foo(){};
    bool initialize()
    {
        return a.Initialize();
    }
    ...
};

Foo obj;

class Foo
{
private:
    AnotherClass a;
    bool m_bInitFail; //store the status of initialization failure

public:
    Foo(bool bInitFail = false) : m_bInitFail(bInitFail)
    {
        m_bInitFail  = a.Initialize();           
    }

    bool GetInitStatus () { return m_bInitFail ; }
};

int main()
{
  Foo fobj;
  bool bStatus = fobj.GetInitStatus();
  return 0;         
}

C ++ sans exceptions est essentiellement une langue complètement différente de C ++, dans laquelle bon nombre des idiomes qui donnent C ++ Son puissance expressive unique sont rendus impuissants. Au fur et à mesure que vous le soulignez, les constructeurs sont dépouillés de leur utilité et que toute initialisation non séventielle doit être déplacée dans un pseudoconstructeur de deuxième étage pouvant renvoyer une indication d'erreur. (Certaines personnes préconisent également un pseudododododestructeur assorti d'un sens erroné de symétrie, mais qui est complètement inutile). Alternativement, le constructeur pourrait définir un drapeau "construit" sur le succès et chaque classe pourrait avoir une méthode "construite" qui vérifie ceci et tous ses enfants.

Si votre entreprise charge que vous désactivez des exceptions, vous aurez également besoin d'une convention à l'échelle de la société (ou au moins à l'échelle du projet) pour la remplacer. Vous devrez définir un type pour toutes les fonctions (non triviales) à revenir et utiliser de manière cohérente partout - sinon, vous obtiendrez un hodge-podge de booléens et incompatibles qui sont passés et convertis manuellement à tous les niveaux. < / p>

Dans ce cas, foo aura également besoin d'une méthode initialiser , qui appelle .Initialize et sort si cela échoue.