exit () llamada dentro de una función que debe devolver una referencia

En una biblioteca, tengo una función que busca una clave en una base de datos y devuelve una referencia no constante a un objeto. Quiero manejar el caso en el que no se encuentra la clave, que normalmente es causada por un error al llamar a la función. Esta situación es tan mala que el progtwig no puede continuar, así que imprimo un mensaje para ayudar a detectar el error y llamar a exit(1) . El problema es con la statement de devolución que nunca se ejecutará en este caso, pero tiene que estar allí de todos modos. Si fuera un puntero, podría simplemente return nullptr; pero con una referencia? ¿Debería hacer algo como este pseudo código?

  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)); } 

¡Se ve tan horrible! Tal vez debería evitar esa función. ¡Por favor déjame saber tu opinión!

Esta situación es tan mala que el progtwig no puede continuar, así que imprimo un mensaje para ayudar a detectar el error y llamar a exit (1)

No. Si este código es parte de una biblioteca, la biblioteca no debería decidir si la aplicación debe salir o no. ¿Qué pasa si un archivo está abierto y necesita cerrarse, o si algún otro recurso necesita ser limpiado, o si el usuario de su clase de base de datos desea registrar el error y continuar haciendo otra cosa?

La respuesta es todo menos lo que estás haciendo ahora. Lanza una excepción, devuelve un código de error, etc. pero no cierres la aplicación dentro de la biblioteca o código de clase.

Lo creas o no, había una biblioteca comercial de DB que hizo exactamente lo que estás haciendo (cerrar la aplicación). Recibieron muchas respuestas enfadadas de parte de los usuarios de su biblioteca sobre por qué cierran inesperadamente la aplicación. Y usted sabe qué, la respuesta dada a los clientes fue que “sentimos que el error fue lo suficientemente grave como para detener la aplicación, porque nuestra biblioteca no puede continuar funcionando correctamente”. Eso no solo es un mal razonamiento, sino que también limita con la arrogancia, y los clientes les hacen saber eso.

Excepciones

Esta es una situación común en muchos progtwigs. Para superar esto, se usan excepciones.

  • Para manejar situaciones inesperadas, se crean nuevas excepciones y se “lanzan” desde el código.
  • Luego tienen que ser “capturados” por el progtwig que llama a la función.

Puede leer más sobre las excepciones aquí .

Espero que esto ayude.

La respuesta, como dijeron los otros encuestados, debería ser: lanzar una excepción …

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

Una biblioteca nunca debería salir de la aplicación hostest.

use “return null”, ingrese en un “estado incoherente” que en cada llamada devuelve NULL.
el usuario de la biblioteca tendrá que manejarlo.

o excepciones …