Usare assert () in C ++ è una cattiva pratica?

Tendo ad aggiungere molte asserzioni al mio codice C ++ per semplificare il debug senza influire sulle prestazioni delle build di rilascio. Ora, assertè una macro C pura progettata senza i meccanismi C ++ in mente.

Il C ++ d'altra parte definisce std::logic_error, che è pensato per essere lanciato nei casi in cui c'è un errore nella logica del programma (da cui il nome). Lanciare un'istanza potrebbe essere solo l'alternativa perfetta e più C ++ a assert.

Il problema è che asserte abortsia terminare il programma immediatamente senza chiamare distruttori, quindi saltare la pulizia, mentre un'eccezione aggiunge manualmente i costi di esecuzione non necessari. Un modo per aggirare questo sarebbe creare una propria macro di asserzione SAFE_ASSERT, che funziona proprio come la controparte C, ma genera un'eccezione in caso di errore.

Posso pensare a tre opinioni su questo problema:

• Attenersi all'asserzione di C. Poiché il programma viene terminato immediatamente, non importa se le modifiche vengono srotolate correttamente. Inoltre, usare #defines in C ++ è altrettanto dannoso.
• Lancia un'eccezione e catturala in main () . Consentire al codice di saltare i distruttori in qualsiasi stato del programma è una cattiva pratica e deve essere evitato a tutti i costi, così come le chiamate a terminate (). Se vengono generate eccezioni, devono essere rilevate.
• Lancia un'eccezione e lascia che termini il programma. Un'eccezione che interrompe un programma va bene e, per NDEBUGquesto motivo, ciò non accadrà mai in una build di rilascio. La cattura non è necessaria ed espone i dettagli di implementazione del codice interno a main().

C'è una risposta definitiva a questo problema? Qualche riferimento professionale?

Modificato: saltare i distruttori, ovviamente, non è un comportamento indefinito.

Le asserzioni sono del tutto appropriate nel codice C ++. Le eccezioni e altri meccanismi di gestione degli errori non sono realmente intesi per la stessa cosa delle asserzioni.

La gestione degli errori è per quando esiste la possibilità di ripristinare o segnalare un errore correttamente all'utente. Ad esempio, se si verifica un errore nel tentativo di leggere un file di input, potresti voler fare qualcosa al riguardo. Gli errori potrebbero derivare da bug, ma potrebbero anche essere semplicemente l'output appropriato per un dato input.

Le asserzioni sono per cose come il controllo che i requisiti di un'API siano soddisfatti quando l'API non sarebbe normalmente controllata, o per controllare cose che lo sviluppatore ritiene di essere garantite dalla costruzione. Ad esempio, se un algoritmo richiede un input ordinato, normalmente non lo verifichi, ma potresti avere un'asserzione per controllarlo in modo che le build di debug contrassegnino quel tipo di bug. Un'asserzione dovrebbe sempre indicare un programma che funziona in modo errato.

Se stai scrivendo un programma in cui un arresto impuro potrebbe causare un problema, potresti voler evitare asserzioni. Un comportamento indefinito strettamente in termini di linguaggio C ++ non si qualifica come un problema del genere qui, poiché colpire un'asserzione è probabilmente già il risultato di un comportamento indefinito, o la violazione di qualche altro requisito che potrebbe impedire il corretto funzionamento di una pulizia.

Inoltre, se si implementano le asserzioni in termini di eccezione, queste potrebbero essere potenzialmente catturate e "gestite" anche se ciò contraddice lo scopo stesso dell'asserzione.

• Le asserzioni servono per il debug . L'utente del codice spedito non dovrebbe mai vederli. Se viene soddisfatta un'asserzione, il codice deve essere corretto.

  CWE-617: asserzione raggiungibile

Il prodotto contiene un'istruzione assert () o simile che può essere attivata da un utente malintenzionato, che porta all'uscita dall'applicazione o ad altri comportamenti più gravi del necessario.

Sebbene l'asserzione sia utile per rilevare errori logici e ridurre le possibilità di raggiungere condizioni di vulnerabilità più gravi, può comunque portare a una negazione del servizio.

Ad esempio, se un server gestisce più connessioni simultanee e una assert () si verifica in una singola connessione che causa la caduta di tutte le altre connessioni, questa è un'asserzione raggiungibile che porta a una negazione del servizio.

• Le eccezioni sono per circostanze eccezionali . Se ne incontra uno, l'utente non sarà in grado di fare ciò che vuole, ma potrebbe essere in grado di riprendere da qualche altra parte.

• La gestione degli errori è per il normale flusso del programma. Ad esempio, se richiedi un numero all'utente e ottieni qualcosa di non analizzabile, è normale , perché l'input dell'utente non è sotto il tuo controllo e devi sempre gestire tutte le possibili situazioni come una cosa ovvia . (Es. Ciclo finché non si dispone di un input valido, dicendo "Mi dispiace, riprova" nel mezzo.)

Le asserzioni possono essere utilizzate per verificare invarianti di implementazione interna, come lo stato interno prima o dopo l'esecuzione di un metodo, ecc. Se l'asserzione fallisce, significa che la logica del programma è rotta e non è possibile ripristinarla. In questo caso il meglio che puoi fare è interrompere il prima possibile senza passare eccezioni all'utente. Ciò che è veramente bello delle asserzioni (almeno su Linux) è che il core dump viene generato come risultato della terminazione del processo e quindi puoi facilmente esaminare la traccia dello stack e le variabili. Questo è molto più utile per comprendere l'errore logico rispetto al messaggio di eccezione.

Non eseguire i distruttori a causa dell'alling abort () non è un comportamento indefinito!

Se lo fosse, allora sarebbe anche un comportamento indefinito da chiamare std::terminate(), e quindi che senso avrebbe fornirlo?

assert() è altrettanto utile in C ++ come in C. Le asserzioni non servono per la gestione degli errori, ma per interrompere immediatamente il programma.

IMHO, le affermazioni servono per verificare le condizioni che, se violate, rendono tutto il resto senza senso. E quindi non puoi riprenderti da loro o meglio, il recupero è irrilevante.

Li raggrupperei in 2 categorie:

• Peccati dello sviluppatore (ad esempio una funzione di probabilità che restituisce valori negativi):

probabilità in virgola mobile () {ritorno -1,0; }

asserire (probabilità ()> = 0,0)

• La macchina è guasta (ad esempio la macchina che esegue il programma è molto sbagliata):

int x = 1;

asserire (x> 0);

Questi sono entrambi esempi banali ma non troppo lontani dalla realtà. Ad esempio, pensa agli algoritmi ingenui che restituiscono indici negativi per l'utilizzo con i vettori. O programmi integrati in hardware personalizzato. O meglio perché succede una merda .

E se si verificano tali errori di sviluppo, non dovresti essere sicuro di alcun meccanismo di ripristino o di gestione degli errori implementato. Lo stesso vale per gli errori hardware.