2009-06-24 2 views

risposta

13

Il contenuto della stringa è definito dall'implementazione, quindi suppongo che la risposta sia sì.

Modifica: Assicuratevi che. Lo standard dice:

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

quindi deve restituire una stringa, non solo un puntatore. E una stringa non può essere NULL. Come altri hanno sottolineato, è facile ricavare eccezioni il cui numero what() restituisce NULL, ma non sono sicuro di come tali aspetti si adeguino alla conformità degli standard. Certamente, se si sta implementando what() nella propria classe di eccezioni, considererei una pratica molto brutta lasciare che restituisca NULL.

Più:

Per un'ulteriore domanda intesa a chiarire se what() può restituire NULL, e simili questioni emozionanti, vedere Extending the C++ Standard Library by inheritance?

+0

Ma se si overwridde cosa ed è catturato da solo const std :: exception e quindi può essere NULL, quindi probabilmente è meglio controllare bene? –

+0

È virtuale, quindi è possibile che i programmatori malintenzionati lo rendano NULL – JaredPar

+0

Interessante. Ora, dal momento che so che alcune persone amano implementare ciò che tramite un metodo std :: string e il metodo c_str(), devo chiedere - può c_str() di un valore correttamente restituito NULL? (Chiedo perché ho questa situazione nella base di codice con cui lavoro e voglio sapere se devo aggiungere qualche TODO o no). –

2

Naturalmente può essere NULL:

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

È possibile farlo ** nella lingua ** (ad es. il tuo codice verrà compilato), ma questo è vietato dallo standard C++ - vedi la risposta di Neil. IOW, non farlo, dal momento che il codice di altre persone potrebbe fare affidamento su di te non farlo. –

+0

Non penso che sia "messo fuori legge" - lo standard specifica il comportamento di std :: exception :: what - non sembra che faccia alcun requisito di classe utente derivante da std :: exception. –

5

Se qualcuno ha ereditato da std :: exception e sovrascritto cosa restituire NULL, quindi questo è possibile.

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

Nonostante eccellente hotel di Neil nella norma, potrebbe essere ancora buono per verificare la presenza di NULL. Sebbene le specifiche di quali classi figlio di std :: state non debbano restituire un valore NULL, nulla nel compilatore imporrà questo codice e il codice sopra sarà comunque legale in base alla lingua.

Questa può essere una situazione ideale per utilizzare un'asserzione ...

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

o

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

perché questo è un caso in cui qualcosa probabilmente non dovrebbe mai mai accadere, e si è ammesso che non dovrebbe accadere, ma vorrebbe comunque sapere (in modalità di debug) quando le tue ipotesi sono mostrate sbagliate. Quindi puoi indirizzare il tuo assunto errato o indirizzare il codice errato che potrebbe andare contro la tua ipotesi (assicurati che what() non restituisca NULL).

+1

È possibile ** nella lingua ** (cioè il tuo codice verrà compilato), ma questo è vietato dallo standard C++ - vedi la risposta di Neil. –

+0

Sì, non sono sicuro se non è un comportamento indefinito se si restituisce solo NULL. Sta violando ciò che specifica per cosa(). –

0

Come molti altri hanno fatto notare, what()non dovrebbe ritorno un puntatore nullo ma facciano altrettanto. Il sovraccarico di runtime di un test nullo si verifica solo nel caso eccezionale in cui, presumibilmente, è meno importante.

In ogni caso, consiglio di utilizzare almeno un assert.

Se lo spazio codice è anche un problema, si spera che lo assert, i test, le revisioni del codice e altri QA siano completi per rintracciare eventuali eccezioni non conformi e non conformi prima della spedizione.

Inoltre, fare attenzione con il codice di gestione delle eccezioni che si possono gettare (ad esempio, come altri hanno notato, l'allocazione di memoria con std::string durante l'elaborazione di un'eccezione std::bad_alloc.)

+0

L'allocazione della memoria non è una buona idea durante l'elaborazione di std :: bad_alloc. Per altre eccezioni, non ha senso non usare std :: string. –