RE:Es correcto pones un exit en el constructor
Si el constructor tiene inicialización que puede resultar errónea, hay varias alternativas. Desde luego, la de hacer un exit es una... pero es demasiado drastica y deja de ser práctica muy a menudo. Además impone muchas restricciones, porque el exit te impide terminar de un modo "elegante" tu aplicación. Además lo de mostrar un mensaje de error en el constructor tampoco es muy elegante. Puede servir en tu aplicación actual si es para consola, pero si quieres reutilizar la clase en un futuro en una aplicación de ventana, ¿qué ocurre con el mensaje escrito con cout o con printf? El usuario no lo vería...
Total, hay que buscar alguna otra solución. La primera que se me ocurre es que la clase tenga una variable booleana que indique si ha habido o no error en el constructor, y obligar a los usuarios de la clase a comprobarlo.
class A {
public: A(...) { ... si hay error, huboError = true; }
getHuboError() { return huboError; }
private: bool huboError;
}
void usoDeClaseA()
A varA(...);
if (varA.huboError()) { ... }
Para evitar que a los usuarios de la clase se les "olvide" comprobar la inicialización, puedes forzar a una inicialización en dos pasos, donde el constructor no hace nada, y luego hay una función que es la que inicializa, recibe los parámetros, y devuelve el error. Si se usa el objeto sin haber hecho la inicialización, todo debe acabar con error, o algo así.
Y la última opción que se me ocurre es la que ha dicho chuidiang, usar excepciones. Aunque un constructor no pueda devolver un valor puede generar una excepción (indicando un error).
class Excepcion {
public:
Excepcion(std::string error) : _error(error) {}
std::string getError() { return _error; }
private:
std::string _error;
};
class Clase {
public:
Clase() { [...]; throw new Excepcion("No pude abrir el fichero"); }
};
void ejemploUso() {
try {
Clase c;
Otras cosas
} catch (Excepcion& e) {
// Manejar convenientemente el error, cuya descripción está en e.getError();
}
}
Espero que te sirva!