exit () appelle à l’intérieur d’une fonction qui devrait retourner une référence

Dans une bibliothèque, j’ai une fonction qui recherche une clé dans une firebase database et renvoie une référence non-const à un object. Je veux gérer le cas dans lequel la clé n’est pas trouvée, ce qui est généralement causé par une erreur lors de l’appel de la fonction. Cette situation est si grave que le programme ne peut pas continuer, aussi j’imprime un message pour aider à repérer le bogue et appeler exit(1) . Le problème est lié à l’instruction return qui ne sera jamais exécutée dans ce cas, mais doit être présente de toute façon. Si c’était un pointeur, je pourrais simplement return nullptr; mais avec une référence? Devrais-je faire quelque chose comme ce pseudo-code?

  Type & get(const Key & k) { if (my_db.key_exists(k)) { return my_db.at(k); } std::cerr << k << " not found\n"; exit(1); return *(new Type(some_dummy_parameters)); } 

Cela a l’air tellement horrible! Peut-être que je devrais juste éviter une telle fonction. S’il te plaît, donnes-moi ton opinion!

Cette situation est si grave que le programme ne peut pas continuer, aussi j’imprime un message pour aider à repérer le bogue et appeler exit (1)

Non. Si ce code fait partie d’une bibliothèque, ce n’est pas à la bibliothèque de décider si l’application doit se fermer ou non. Que faire si un fichier est ouvert et doit être fermé, ou si une autre ressource doit être nettoyée, ou si l’utilisateur de votre classe de firebase database veut consigner l’erreur et continuer à faire autre chose?

La réponse est tout sauf ce que vous faites maintenant. Lancez une exception, retournez un code d’erreur, etc., mais ne fermez pas l’application dans le code de la bibliothèque ou de la classe.

Croyez-le ou non, il y avait une bibliothèque de firebase database commerciale qui faisait exactement ce que vous faisiez (fermer l’application). Les utilisateurs de leur bibliothèque ont exprimé beaucoup de colère sur les raisons pour lesquelles ils ont fermé l’application de manière inattendue. Et vous savez quoi – la réponse donnée aux clients était que “nous avons estimé que l’erreur était suffisamment grave pour arrêter l’application, car notre bibliothèque ne peut pas continuer à fonctionner correctement”. Ce n’est pas seulement un mauvais raisonnement, cela frise l’arrogance et les clients le leur font savoir.

Exceptions

C’est une situation courante dans de nombreux programmes. Pour surmonter cela, des exceptions sont utilisées.

  • Pour gérer les situations inattendues, de nouvelles exceptions sont créées et “rejetées” du code.
  • Ensuite, ils doivent être “attrapés” par le programme appelant la fonction.

Vous pouvez en savoir plus sur les exceptions ici .

J’espère que cela t’aides.

La réponse, comme l’ont dit les autres répondants, devrait être: jetez une exception …

 Type & get(const Key & k) { if( !my_db.key_exists(k) ) { std::ssortingngstream error; error << "key " << k << " not found"; throw std::runtime_error(error); } return my_db.at(k); } 

Une bibliothèque ne doit jamais quitter l’application hôte.

utilisez “return null”, entrez dans un “état incohérent” qui, à chaque appel, vous renvoyez NULL.
l’utilisateur de la bibliothèque devra s’en charger.

ou des exceptions …