C++ excepciones, ¿qué() puede ser NULO?

Question

¿Puede una excepción std :: capturada tener alguna vez que() sea NULO?

¿Está la comprobación de e.what() debajo de la sobrecarga?

//... 
} 
catch (const std::exception& e) 
{ 
    std::string error; 
    if(e.what()) 
    error = e.what(); 
} 

Answer 1

El contenido de la cadena está definido por la implementación, así que supongo que la respuesta es sí.

Edit: Belay that. El estándar dice:

virtual const char* what() const throw(); 
5 Returns: An implementation-defined NTBS. 

Por lo tanto, debe devolver una cadena, no solo un puntero. Y una cadena no puede ser NULL. Como han señalado otros, es fácil derivar excepciones cuyo what() devuelve NULL, pero no estoy seguro de cómo encajan tales cosas en la conformidad de los estándares. Ciertamente, si está implementando what() en su propia clase de excepción, consideraría muy mala práctica permitir que devuelva NULL.

Más:

Por otra cuestión que se estudie si what() puede devolver NULL, y las cuestiones interesantes similares, vea Extending the C++ Standard Library by inheritance?

Answer 2

Por supuesto que puede ser NULL:

class myexception: public exception 
{ 
    virtual const char* what() const throw() 
    { 
    return NULL; 
    } 
} myex; 

Answer 3

Si alguien ha heredado de std :: exception y anulado qué devolver NULL, entonces esto es posible.

class CMyException : public std::exception 
    { 
    ... 
     virtual const char * what() const {return NULL;} 
    }; 

A pesar de encontrar excelente en el estándar de Neil, podría ser bueno comprobar si es NULO. Aunque las especificaciones de las clases secundarias de std :: exception indican que no deben devolver un valor NULL, nada en el compilador hará cumplir esto y el código anterior seguirá siendo legal según el idioma.

Esto puede ser una situación ideal para utilizar una aserción ...

assert(except.what() != NULL); 

o

if (except.what() != NULL) 
{ 
     ... normal processing ... 
} 
else 
{ 
     assert(false); 
} 

porque se trata de un caso en el que algo probablemente nunca llegase a ocurrir, y que está suponiendo que no debería suceder, pero aún me gustaría saber (en modo de depuración) cuando se demuestra que sus suposiciones son incorrectas. Entonces puede abordar su suposición incorrecta o abordar el código incorrecto que puede ir en contra de su suposición (asegúrese de que() no devuelva NULL).

Answer 4

Como muchos otros han señalado, what()no debería retorno a un puntero nulo pero podría. La sobrecarga de tiempo de ejecución de una prueba nula solo se produce en el caso excepcional donde, presumiblemente, es menos importante.

En cualquier caso, lo recomendaría al menos usando un assert.

Si el espacio del código también es una preocupación, con suerte el assert, sus pruebas, revisiones de código y otros QA estarán lo suficientemente completos para rastrear cualquier excepción ofensiva y no conforme antes de enviar.

Además, tenga cuidado con el código de control de excepciones que puede en sí mismo tirar (por ejemplo, como han dicho otros, la asignación de memoria con std::string al procesar una excepción std::bad_alloc.)