Meilleure façon de revenir tôt à partir d'une fonction renvoyant une référence

Si vous ne voulez pas jeter une exception, vous pouvez essayer quelque chose comme:

const SomeObject& GetSomeObject(const SomeObject& default_if_not_found = SomeObject())
{
    // ...
    if (!found)
        return default_if_not_found;

    return ourObject;
}

Je crois que la réponse dépend de la question de savoir si vous êtes le genre de programmeur qui considère comme mauvais et ne veut jamais les utiliser ou non. Si vous les utilisez, et c'est vraiment une condition exceptionnelle, une exception doit être lancée. Oui, les utilisateurs doivent y faire face, mais cacher une erreur pour prétendre que rien n'est arrivé n'est tout simplement pas une option. Mais si vous n'utilisez jamais d'exceptions, rendez-vous simplement un pointeur ou un booléen et ajoutez une référence non constituée à votre fonction. Les deux solutions sont simples, mais qui ont dit que les choses trop complexes rendent le code mieux?

Je ferais probablement cela: xxx

et peut-être aussi: xxx

Les appelants ont alors quelques options: xxx

Vous concevez une interface de la fonction différemment en fonction de ce que sont les conditions préalables, c'est-à-dire dont la responsabilité est de s'assurer qu'elle peut faire son travail.

Si c'est la responsabilité de l'appelant, Ensuite, ils ont besoin de la capacité de s'assurer que cela. Vous voudrez peut-être vérifier quand même, juste pour être du côté sûr. Jeter une exception lorsque les «conditions préalées» ne sont pas remplies les rendent plus comme des conseils que les conditions, et cela peut fonctionner assez bien à condition que cela ne vous dérange pas des frais de contrôle des chèques d'exécution partout. Je suis généralement assez impitoyable avec des conditions préalables, je pourrais donc remplacer l'exception conditionnelle avec une affirmation et documenter que la fonction ne doit pas être appelée en mode incorrect. Cela dépend de la quantité de contrôle de l'appelant sur le mode - évidemment s'il change de manière arbitraire (par exemple, si "la somécontion" est "il n'y a pas d'octet disponible sur le UART"), vous avez besoin d'une interface très différente de si elle ne change que jamais Lorsque le code client appelle une fonction pour le modifier.

Si ce n'est pas la responsabilité de l'appelant d'obtenir le mode droit, votre interface ne doit pas écrire des chèques que votre implémentation ne peut pas encaisser. Dans ce cas s'il est "attendu" qu'il n'y aura aucun objet de retour, le retour ne devrait pas être par référence. Sauf indication contraire (A), vous pouvez franchir une spéciale "désolé, il n'a pas fonctionné" objet à retourner, que l'appelant peut vérifier, ou (b) vous êtes à l'aise de lancer des exceptions dans les situations "attendues". IMO (B) est rare en C ++. (a) n'est généralement pas mieux que de retourner un pointeur NULL, mais de temps en temps. Par exemple, retourner une collection vide pour signifier "Il n'y a rien que vous êtes autorisé à voir ici" peut entraîner un code d'appel très propre, si DosomeLeelse () aurait été "ne rien faire". Donc, ainsi que les responsabilités souhaitées, l'interface dépend des cas d'utilisation attendus.