C++ Ramificaciones de ignorar la excepción del constructor

Question

He buscado SO para obtener una respuesta a esto, pero no he encontrado ninguna.

Cuando un objeto arroja una excepción al final del constructor, ¿el objeto es válido o es uno de esos "depende de la técnica de construcción"?

Ejemplo:

struct Fraction 
    { 
     int m_numerator; 
     int m_denominator; 
     Fraction (double value, 
       int denominator); 
    }; 
    Fraction::Fraction(double value, int denominator) 
    : m_numerator(0), m_denominator(denominator) 
    { 
     if (denominator == 0) 
     { 
/* E1 */  throw std::logic_error("Denominator is zero."); 
     } 
     m_numerator = static_cast<int>(value * static_cast<double>(denominator)); 
     double actual_value = 0.0; 
     actual_value = static_cast<double>(m_numerator)/static_cast<double>(m_denominator); 
     double error = fabs(actual_value - value); 
     if (error > 5.0E-5) 
     { 
/* E2 */ throw std::logic_error("Can't represent value in exact fraction with given denominator"); 
     } 
    } 

El programa:

int main(void) 
{ 
    try 
    { 
     Fraction f1(3.14159264, 4); // Throws exception, E2 above. 
    } 
    catch (...) 
    { 
     cerr << "Fraction f1 not exactly representable as fraction with denom. of 4.\n"; 
    } 

    // At this point, can I still use f1, knowing that it is an approximate fraction? 

    return EXIT_SUCCESS; 
} 

En este ejemplo, puede ser utilizado F1 después se detecta la excepción, sabiendo que es un valor aproximado?

Los miembros de datos se han construido e inicializado.

No veo ninguna regla de lenguaje C++ violada por lo anterior.

Editar: Se ha cambiado el valor delta de error de 5.0E05 a 5.0E-5.

Answer 1

La respuesta de Jonathan es correcta. Además, aunque la fracción puede estar en un estado válido, no recomendaría el uso de excepciones para control de flujo, y especialmente para la comunicación sobre el estado de un objeto. En su lugar, considere agregar algún tipo de is_exactly_representable a su API de objeto Fraction que devuelve bool.

Answer 2

f1 está fuera del alcance después de que se captura la excepción. Ya no existe, por lo que no puedes usarlo.

Answer 3

Estoy de acuerdo con fbrereto.

Si arroja un error en un constructor que es equivalente a decir "la construcción de este objeto no funcionó" o "no se pudo crear el objeto" y como tal, debe manejar ese hecho, yo solo Haga esto para los errores fatales para los cuales el objeto no se puede usar de otra manera, como no se pudo abrir un archivo que esperábamos poder abrir en la clase MySettingsReader.

Answer 4

No, una vez que el alcance que se define f1 en las salidas, ya no puede usar el objeto. Por lo tanto, en el código:

try 
{ 
    Fraction f1(3.14159264, 4); // Throws exception, E2 above. 

    // f1 can be used until here 
} 
catch (...) 
{ 
} 

// The scope that f1 was defined in is over, so the compiler will not let 
// you reference f1 

Dicho esto, tal vez debería replantearse lanzar una excepción cuando no se puede representar el valor real . Debido a que sólo puede ser aplicable para ciertos usos, que podría requerir la persona que llama para que lo solicite:

enum FractionOption { disallowInexact, allowInexact }; 

Fraction::Fraction(double value, int denominator, 
        FractionOption option = disallowInexact) 
{ 
    ... 
    if ((option == disallowInexact) && (error > 5.0E-5)) 
    { 
     throw std::logic_error("Can't represent value ..."); 
    } 
} 

Fraction f1(3.14159264, 4, allowInexact); 

Answer 5

Si un objeto se produce una excepción durante la construcción no invalida el objeto técnico. En su ejemplo, f1 queda fuera del alcance y, por lo tanto, se desasigna cuando se lanza la excepción.

Si f1 era un puntero que se asignaron y construyeron dentro del bloque try, y el constructor (no el asignador) arrojó una excepción, su puntero sería a la memoria asignada válida. Si el objeto en esa memoria contenía o no datos válidos dependería de tu constructor; Básicamente, si los datos eran válidos antes del lanzamiento, serían válidos después del lanzamiento.

También parece que lo que está intentando hacer no es un uso apropiado para las excepciones, y cuestionaría su diseño aquí.Lanzar una excepción en una llamada de constructor generalmente significa que el objeto no se construyó correctamente y no se debe usar.

Answer 6

siguiente JMD

es entonces f1 disponibles en la cláusula catch. La respuesta es también no. ASÍ MISMO, ves que las reglas de alcance te impiden incluso hacer esta pregunta en el código.

La única cosa que le daría a distancia que el objeto existiera sería si su destructor pasó - pero no se ejecuta si el contructor no completó

Answer 7

tiro en el constructor de construcción = no -> objeto inutilizable

Como ya se mencionó, si se lanza la excepción, entonces el objeto queda fuera del alcance. Sin embargo, usted puede estar interesado en el caso cuando se asigna un objeto:

f = new Fraction(3.14159264, 4); 

En este caso, f también es inservible, porque el constructor no terminó el trabajo, y el puntero no se asignan. El destructor no se llama, y ​​la memoria es desasignada, por lo tanto, no hay forma de utilizar el objeto.

Por lo tanto, construya su objeto normalmente, no use excepciones si tiene la intención de utilizar la clase. Use una función de miembro is_exact() para decidir si es exacto después de la construcción.

Answer 8

Cuando un objeto se produce una excepción al final del constructor, es el objeto válido o se trata de uno de los 'depende de la técnica de construcción'?

Sí, depende hecho. Quiero decir, depende de lo que signifique que el objeto es válido. Válido puede tener varios significados.

Lo que se sabe es que un objeto cuya construcción se ha interrumpido es un objeto parcialmente construido. Ahora, si considera la construcción parcial como un estado inválido, entonces sí, dicho objeto no será válido.

La destrucción es sin embargo garantizada de acuerdo con este esquema se especifica en C++/15,2:

un objeto que es parcialmente construido o parcialmente destruidos habrá destructores ejecuta para todos los de sus subobjetos totalmente construido, es decir, para subobjetos para los cuales el constructor ha completado la ejecución y el destructor aún no ha comenzado la ejecución .

Esto significa, que sólo los subobjetos de objeto construido parcialmente estarán debidamente destruidos pero destructor de sí mismo objeto construido parcialmente se no ser llamados.

#include <iostream> 
using namespace std; 
struct A 
{ 
    ~A() { cout<<"~A()\n"; } 
}; 
struct B 
{ 
    A a; 
    B() { throw 1; } 
    ~B() { cout<<"~B()\n"; } // never called 
}; 
int main() 
{ 
    try 
    { 
     B a; 
    } 
    catch (...) 
    { 
     cout << "caught\n"; 
    } 
} 

Answer 9

Si en cualquier fase durante el constructor se produce una excepción (y no atrapado dentro del constructor), no existirá el objeto.Todas las variables miembro que ya se han construido con éxito serán deconstruidas en el orden inverso exacto de construcción. Si la excepción fue lanzada desde un constructor de variables miembro o de otra manera dentro de la lista de inicialización, la variable miembro que no pudo construir no tiene su destructor llamado, y ninguno tiene lo que viene después.

En cualquier caso, suponiendo que usa RAII en todas partes, todos los recursos se liberan correctamente y no habrá ningún objeto al que acceder. En el caso de ptr = new Foo();, la variable ptr conserva su valor anterior. Del mismo modo smartptr.reset(new Foo()); no llamará a la función de reinicio en absoluto.

Observe la falacia de usar el operador nuevo en las expresiones que construyen otros objetos: somefunc(Foo(), new Bar());. Si el constructor Foo falla, puede haber una pérdida de memoria (dependiendo del orden en que el compilador procesó los argumentos).