Quando le asserzioni dovrebbero rimanere nel codice di produzione? [chiuso]

C'è una discussione in corso su comp.lang.c ++. Moderata sull'opportunità che le asserzioni, che in C ++ esistono solo nelle build di debug per impostazione predefinita, debbano essere mantenute nel codice di produzione o meno.

Ovviamente, ogni progetto è unico, quindi la mia domanda qui non è tanto se le affermazioni debbano essere mantenute, ma in quali casi è consigliabile / non è una buona idea.

Per affermazione, intendo:

• Un controllo di runtime che verifica una condizione che, se falsa, rivela un bug nel software.
• Un meccanismo mediante il quale il programma viene interrotto (forse dopo un lavoro di pulizia davvero minimo).

Non sto necessariamente parlando di C o C ++.

La mia opinione è che se sei il programmatore, ma non possiedi i dati (come nel caso della maggior parte delle applicazioni desktop commerciali), dovresti tenerli attivi, perché un'asserzione fallita mostra un bug e non dovresti andare con un bug, con il rischio di corrompere i dati dell'utente. Questo ti costringe a testare con forza prima della spedizione e rende più visibili i bug, quindi più facili da individuare e correggere.

Qual è la tua opinione / esperienza?

Saluti,

Carl

Vedi la domanda correlata qui

Risposte e aggiornamenti

Ehi Graham,

Un'affermazione è un errore, pura e semplice e quindi dovrebbe essere gestita come una. Dal momento che un errore dovrebbe essere gestito in modalità di rilascio, non hai davvero bisogno di asserzioni.

Ecco perché preferisco la parola "bug" quando parlo di asserzioni. Rende le cose molto più chiare. Per me, la parola "errore" è troppo vaga. Un file mancante è un errore, non un bug, e il programma dovrebbe gestirlo. Cercare di dereferenziare un puntatore nullo è un bug e il programma dovrebbe riconoscere che qualcosa ha un cattivo odore.

Pertanto, è necessario testare il puntatore con un'asserzione, ma la presenza del file con il normale codice di gestione degli errori.

Leggero fuori tema, ma un punto importante nella discussione.

Come avvertimento, se le tue affermazioni si infrangono nel debugger quando falliscono, perché no. Ma ci sono molte ragioni per cui un file potrebbe non esistere completamente al di fuori del controllo del tuo codice: diritti di lettura / scrittura, disco pieno, dispositivo USB scollegato, ecc. Dato che non hai il controllo su di esso, penso che le affermazioni siano non è il modo giusto di affrontarlo.

Carl

Tommaso,

Sì, ho il codice completo e devo dire che non sono assolutamente d'accordo con quel particolare consiglio.

Supponi che l'allocatore di memoria personalizzato si rovini e azzeri un pezzo di memoria ancora utilizzato da qualche altro oggetto. Mi capita di azzerare un puntatore che questo oggetto dereferenzia regolarmente e uno degli invarianti è che questo puntatore non è mai nullo e hai un paio di affermazioni per assicurarti che rimanga tale. Cosa fai se il puntatore è improvvisamente nullo. Hai solo () intorno, sperando che funzioni?

Ricorda, stiamo parlando del codice prodotto qui, quindi non è possibile entrare nel debugger e ispezionare lo stato locale. Questo è un vero bug sul computer dell'utente.

Carl

Le asserzioni sono commenti che non diventano obsoleti. Documentano quali stati teorici sono previsti e quali stati non dovrebbero verificarsi. Se il codice viene modificato in modo da consentire la modifica degli stati, lo sviluppatore viene presto informato e deve aggiornare l'asserzione.

Consentitemi di citare il codice completo di Steve McConnell. La sezione sulle asserzioni è 8.2.

Normalmente, non si desidera che gli utenti vedano i messaggi di asserzione nel codice di produzione; le affermazioni servono principalmente durante lo sviluppo e la manutenzione. Le asserzioni vengono normalmente compilate nel codice in fase di sviluppo e compilate fuori dal codice per la produzione.

Tuttavia, più avanti nella stessa sezione, viene fornito questo consiglio:

Per un codice altamente affidabile, asserire e quindi gestire l'errore comunque.

Penso che fintanto che le prestazioni non sono un problema, lasciate l'asserzione, ma piuttosto che visualizzare un messaggio, fatelo scrivere in un file di registro. Penso che il consiglio sia anche in Codice completo, ma non lo trovo in questo momento.

Lascia le asserzioni attivate nel codice di produzione, a meno che tu non abbia misurato che il programma funziona in modo significativamente più veloce con quelle disattivate.

se non vale la pena misurarlo per dimostrare che è più efficiente, non vale la pena sacrificare la chiarezza per una scommessa da esibizione ". - Steve McConnell 1993

http://c2.com/cgi/wiki?ShipWithAssertionsOn

Se stai anche pensando di lasciare affermazioni in produzione, probabilmente stai pensando a loro in modo sbagliato. Il punto centrale delle affermazioni è che è possibile disattivarle durante la produzione, perché non fanno parte della soluzione. Sono uno strumento di sviluppo, utilizzato per verificare che i tuoi presupposti siano corretti. Ma nel momento in cui entri in produzione, dovresti già avere fiducia nei tuoi presupposti.

Detto questo, c'è un caso in cui accenderò le asserzioni in produzione: se incontriamo un bug riproducibile in produzione che stiamo facendo fatica a riprodurre in un ambiente di test, può essere utile riprodurre il bug con asserzioni attivate in produzione, per vedere se forniscono informazioni utili.

Una domanda più interessante è questa: nella fase di test, quando disattivi le affermazioni?

Le asserzioni non dovrebbero mai rimanere nel codice di produzione. Se una particolare asserzione sembra che potrebbe essere utile nel codice di produzione, allora non dovrebbe essere una asserzione; dovrebbe essere un controllo di errore fase di esecuzione, vale a dire qualcosa di codice come questo: if( condition != expected ) throw exception.

Il termine "asserzione" significa "un controllo del solo tempo di sviluppo che non verrà eseguito sul campo".

Se inizi a pensare che le asserzioni potrebbero arrivare sul campo, allora inevitabilmente inizierai anche a fare altri pensieri pericolosi, come chiederti se vale davvero la pena dare una determinata asserzione. Non vi è alcuna affermazione che non valga la pena di fare. Non dovresti mai chiederti "dovrei affermarlo o no?" Dovresti solo chiederti "C'è qualcosa che ho dimenticato di affermare?"

A meno che la profilazione non mostri che le asserzioni stanno causando problemi di prestazioni, dico che dovrebbero rimanere anche nella versione di produzione.

Tuttavia, penso che ciò richieda anche che tu gestisca i fallimenti delle asserzioni in modo piuttosto elegante. Ad esempio, dovrebbero tradursi in un tipo generale di finestra di dialogo con l'opzione di segnalare (automaticamente) il problema agli sviluppatori e non semplicemente chiudere o arrestare il programma. Inoltre, dovresti stare attento a non usare le asserzioni per le condizioni che in realtà permetti, ma possibilmente non ti piacciono o consideri indesiderate. Tali condizioni dovrebbero essere gestite da altre parti del codice.

Nel mio C ++ definisco REQUIRE (x) che è come assert (x) tranne per il fatto che genera un'eccezione se l'asserzione fallisce in una build di rilascio.

Poiché un'asserzione non riuscita indica un bug, dovrebbe essere trattata seriamente anche in una build di rilascio. Quando le prestazioni del mio codice sono importanti, userò spesso REQUIRE () per un codice di livello superiore e assert () per un codice di livello inferiore che deve essere eseguito rapidamente. Uso anche REQUIRE invece di affermare se la condizione di errore potrebbe essere causata da dati trasmessi dal codice scritto da una terza parte o dalla corruzione dei file (in modo ottimale progetterei il codice specificamente per comportarsi bene in caso di corruzione dei file, ma noi non sempre ho tempo per farlo.)

Dicono che non dovresti mostrare quei messaggi di asserzione agli utenti finali perché non li capiranno. Così? Gli utenti finali possono inviarti un'e-mail con una schermata o del testo del messaggio di errore, che ti aiuta a eseguire il debug. Se l'utente dice semplicemente "si è bloccato", hai meno possibilità di risolverlo. Sarebbe meglio inviarti automaticamente i messaggi di errore di asserzione su Internet, ma questo funziona solo se l'utente ha accesso a Internet e puoi ottenere il suo permesso.

Se si desidera mantenerli, sostituirli con la gestione degli errori. Niente di peggio di un programma che sta scomparendo. Non vedo nulla di male nel trattare alcuni errori come bug gravi, ma dovrebbero essere indirizzati a una sezione del programma che è attrezzata per gestirli raccogliendo, registrandoli e informando l'utente che la tua app ha avuto delle condizioni indesiderate e sta uscendo.

A condizione che vengano gestiti proprio come qualsiasi altro errore, non vedo alcun problema. Tieni presente, tuttavia, che le asserzioni non riuscite in C, come con altre lingue, usciranno semplicemente dal programma, e questo di solito non è sufficiente per i sistemi di produzione.

Esistono alcune eccezioni: PHP, ad esempio, ti consente di creare un gestore personalizzato per errori di asserzione in modo da poter visualizzare errori personalizzati, effettuare registrazioni dettagliate, ecc. Invece di uscire.

Il nostro software per database server contiene affermazioni sia di produzione che di debug. Le asserzioni di debug sono proprio questo: vengono rimosse nel codice di produzione. Le asserzioni di produzione si verificano solo se (a) esiste una condizione che non dovrebbe mai esistere e (b) non è possibile recuperare in modo affidabile da questa condizione. Un'asserzione di produzione indica che si è verificato un errore nel software o si è verificato un tipo di danneggiamento dei dati.

Poiché si tratta di un sistema di database e stiamo archiviando dati potenzialmente importanti per l'azienda, facciamo tutto il possibile per evitare dati corrotti. Se esiste una condizione che potrebbe indurci a memorizzare dati errati, affermiamo immediatamente, ripristiniamo tutte le transazioni e arrestiamo il server.

Detto questo, cerchiamo anche di evitare asserzioni di produzione in routine critiche per le prestazioni.

Vedo asserzioni come test unitari in linea. Utile per un test rapido durante lo sviluppo, ma alla fine quelle affermazioni dovrebbero essere rifatte da essere testate esternamente in test unitari.

Trovo che sia meglio gestire tutti gli errori che rientrano nell'ambito e utilizzare le asserzioni per le ipotesi che stiamo affermando SONO vere.

cioè, se il tuo programma sta aprendo / leggendo / chiudendo un file, non essere in grado di aprire il file è nell'ambito - è una possibilità reale, che sarebbe negligente da ignorare, in altre parole. Quindi, dovrebbe avere un codice di controllo degli errori associato ad esso.

Tuttavia, supponiamo che fopen () sia documentato come sempre restituendo un handle di file aperto e valido. Si apre il file e lo si passa alla funzione readfile ().

Quella funzione di readfile, in questo contesto, e probabilmente secondo le sue specifiche di progettazione, può praticamente supporre che otterrà un file ptr valido. Pertanto, sarebbe inutile aggiungere un codice di gestione degli errori per il caso negativo, in un programma così semplice. Tuttavia, dovrebbe almeno documentare l'assunto, in qualche modo - assicurarsi in qualche modo - che questo sia effettivamente il caso, prima di continuare la sua esecuzione. NON dovrebbe REALMENTE presumere che sarà sempre valido, nel caso in cui venga chiamato in modo errato, o sia copiato / incollato in qualche altro programma, ad esempio.

Quindi, readfile () {assert (fptr! = NULL); ..} è appropriato in questo caso, mentre la completa gestione degli errori non lo è (ignorando il fatto che la lettura effettiva del file richiederebbe comunque un sistema di gestione degli errori).

E sì, quelle affermazioni dovrebbero rimanere nel codice di produzione, a meno che non sia assolutamente necessario disabilitarle. Anche allora, probabilmente dovresti disabilitarli solo nelle sezioni critiche per le prestazioni.

Supponiamo che un pezzo di codice sia in produzione e colpisca un'asserzione che normalmente verrebbe attivata. L'asserzione ha trovato un bug! Tranne il contrario, perché l'affermazione è disattivata.

Quindi cosa succede adesso? O il programma (1) si arresterà in modo non informativo in un punto ulteriormente rimosso dalla fonte del problema o (2) funzionerà allegramente fino al completamento, probabilmente dando il risultato sbagliato.

Nessuno dei due scenari è invitante. Lascia le asserzioni attive anche in produzione.

Raramente uso asserzioni per qualsiasi altra cosa che compili il controllo del tipo di tempo. Vorrei usare un'eccezione anziché un'asserzione solo perché la maggior parte delle lingue sono costruite per gestirle.

Offro un esempio

file = create-some-file();
_throwExceptionIf( file.exists() == false, "FILE DOES NOT EXIST");

contro

file = create-some-file();
ASSERT(file.exists());

In che modo l'applicazione gestirà l'affermazione? Preferisco il vecchio try catchmetodo di gestione degli errori fatali.

Il più delle volte, quando uso l'asserzione in java (la parola chiave assert), aggiungo automaticamente alcuni codici di produzione dopo. Secondo il caso, può essere un messaggio di registrazione, un'eccezione ... o niente.

Secondo me, tutte le tue affermazioni sono fondamentali nella versione dev, non nella produzione relase. Alcuni devono essere tenuti, altri devono essere scartati.

Le asserzioni non sono errori e non devono essere gestite come errori. Quando viene lanciata un'asserzione, ciò significa che c'è un bug nel tuo codice o in alternativa nel codice che chiama il tuo codice.

Vi sono alcuni punti da evitare per abilitare le asserzioni nel codice di produzione: 1. Non si desidera che l'utente finale visualizzi un messaggio del tipo "ASSERZIONE non riuscita MyPrivateClass.cpp riga 147. L'utente finale NON è un ingegnere addetto al controllo qualità. 2. L'ASSERENZA potrebbe influenza le prestazioni

Tuttavia, esiste un motivo valido per abbandonare le asserzioni: ASSERTION potrebbe influenzare le prestazioni e i tempi, e purtroppo questo a volte è importante (specialmente nei sistemi embedded).

Tendo a votare per aver lasciato l'affermazione nel codice di produzione ma assicurandomi che queste stampe non siano esposte all'utente finale.

~ Yitzik

Un'affermazione è un errore, pura e semplice e quindi dovrebbe essere gestita come una.

Dal momento che un errore dovrebbe essere gestito in modalità di rilascio, non hai davvero bisogno di asserzioni.

Il vantaggio principale che vedo per le asserzioni è un'interruzione condizionale: sono molto più facili da configurare rispetto al perforare le finestre di VC per impostare qualcosa che richiede 1 riga di codice.