Condividi tramite

Asserzioni nel codice gestito

Un'asserzione, o istruzione Assert, verifica una condizione specificata come argomento dell'istruzione Assert. Se la condizione restituisce true, non viene eseguita alcuna azione. Se restituisce false, l'asserzione ha esito negativo. Se è in esecuzione una build di debug, il programma passa alla modalità di interruzione.

In questo argomento

Asserzioni nel namespace System.Diagnostics

Metodo Debug.Assert

Effetti collaterali di Debug.Assert

Requisiti di tracciamento e debug

Conferma argomenti

Personalizzazione del comportamento di Asserzione

Impostazione delle asserzioni nei file di configurazione

Asserzioni nello spazio dei nomi System.Diagnostics

In Visual Basic e Visual C# è possibile usare il metodo Assert da Debug o Trace, che si trovano nel namespace System.Diagnostics. Debug I metodi di classe non sono inclusi in una versione Release del programma, quindi non aumentano le dimensioni o riducono la velocità del codice di rilascio.

C++ non supporta i metodi della Debug classe. È possibile ottenere lo stesso effetto usando la classe con la Trace compilazione condizionale, ad esempio #ifdef DEBUG... #endif.

Contenuto dell'argomento

Metodo Debug.Assert

Utilizzare il metodo System.Diagnostics.Debug.Assert per verificare le condizioni che devono restituire true se il codice è corretto. Si supponga, ad esempio, di aver scritto una funzione di divisione integer. In base alle regole matematiche, il divisore non può mai essere zero. È possibile testarlo usando un'asserzione:

int IntegerDivide ( int dividend , int divisor )
{
    Debug.Assert ( divisor != 0 );
    return ( dividend / divisor );
}

Quando si esegue questo codice nel debugger, l'istruzione di asserzione viene valutata, ma nella versione Release il confronto non viene eseguito, quindi non è previsto alcun sovraccarico aggiuntivo.

Ecco un altro esempio. Hai una classe che implementa un conto corrente, come indicato di seguito:

float balance = savingsAccount.Balance;
Debug.Assert ( amount <= balance );
savingsAccount.Withdraw ( amount );

Prima di ritirare denaro dal conto, si desidera assicurarsi che il saldo del conto sia sufficiente per coprire l'importo che si sta preparando a ritirare. È possibile scrivere un'asserzione per controllare il saldo:

float balance = savingsAccount.Balance;
Trace.Assert ( amount <= balance );
savingsAccount.Withdraw ( amount );

Si noti che le chiamate al System.Diagnostics.Debug.Assert metodo scompaiono quando si crea una versione Release del codice. Ciò significa che la chiamata che controlla il saldo scompare nella versione release. Per risolvere questo problema, è necessario sostituire System.Diagnostics.Debug.Assert con System.Diagnostics.Trace.Assert, che non scompare nella versione di rilascio:

Le chiamate a System.Diagnostics.Trace.Assert aggiungono overhead alla tua versione Release, diversamente dalle chiamate a System.Diagnostics.Debug.Assert.

Contenuto dell'argomento

Effetti collaterali di Debug.Assert

Quando si usa System.Diagnostics.Debug.Assert, assicurarsi che qualsiasi codice all'interno Assert non modifichi i risultati del programma se Assert viene rimosso. In caso contrario, è possibile introdurre accidentalmente un bug che viene visualizzato solo nella versione release del programma. Prestare particolare attenzione alle asserzioni che contengono chiamate di funzione o di routine, ad esempio l'esempio seguente:

// unsafe code
Debug.Assert (meas(i) != 0 );

Questo uso di System.Diagnostics.Debug.Assert potrebbe apparire sicuro a prima vista, ma si supponga che la funzione meas aggiorni un contatore ogni volta che viene chiamato. Quando si compila la versione release, questa chiamata a meas viene eliminata, quindi il contatore non viene aggiornato. Questo è un esempio di una funzione con un effetto collaterale. L'eliminazione di una chiamata a una funzione con effetti collaterali potrebbe causare un bug visualizzato solo nella versione release. Per evitare questi problemi, non inserire chiamate di funzione in un'istruzione System.Diagnostics.Debug.Assert . Usare invece una variabile temporanea:

temp = meas( i );
Debug.Assert ( temp != 0 );

Anche quando si usa System.Diagnostics.Trace.Assert, è comunque consigliabile evitare di inserire chiamate di funzione all'interno di un'istruzione Assert . Queste chiamate devono essere sicure, perché System.Diagnostics.Trace.Assert le istruzioni non vengono eliminate in una versione di rilascio. Tuttavia, se si evitano tali costrutti come abitudine, è meno probabile che si commette un errore quando si usa System.Diagnostics.Debug.Assert.

Contenuto dell'argomento

Requisiti per la tracciatura e il debug

Se si crea il progetto usando le procedure guidate di Visual Studio, il simbolo TRACE viene definito per impostazione predefinita nelle configurazioni Release e Debug. Il simbolo DEBUG è definito per impostazione predefinita solo nella build di debug.

In caso contrario, affinché Trace i metodi funzionino, il programma deve avere uno dei seguenti elementi all'inizio del file di origine:

Verificare gli argomenti

System.Diagnostics.Trace.Assert e System.Diagnostics.Debug.Assert accettano fino a tre argomenti. Il primo argomento, obbligatorio, è la condizione da controllare. Se si chiama System.Diagnostics.Trace.Assert(Boolean) o System.Diagnostics.Debug.Assert(Boolean) con un solo argomento, il Assert metodo controlla la condizione e, se il risultato è false, restituisce il contenuto dello stack di chiamate nella finestra Output . L'esempio seguente mostra System.Diagnostics.Trace.Assert(Boolean) e System.Diagnostics.Debug.Assert(Boolean):

Debug.Assert ( stacksize > 0 );
Trace.Assert ( stacksize > 0 );

Il secondo e il terzo argomento, se presenti, devono essere stringhe. Se si chiama System.Diagnostics.Trace.Assert o System.Diagnostics.Debug.Assert con due o tre argomenti, il primo argomento è una condizione. Il metodo controlla la condizione e, se il risultato è false, restituisce la seconda stringa e la terza stringa. Nell'esempio seguente vengono mostrati System.Diagnostics.Debug.Assert(Boolean, String) e System.Diagnostics.Trace.Assert(Boolean, String) usati con due argomenti:

Debug.Assert ( stacksize > 0, "Out of stack space" );
Trace.Assert ( stacksize > 0, "Out of stack space" );

Nell'esempio seguente vengono mostrati System.Diagnostics.Debug.Assert(Boolean, String, String) e System.Diagnostics.Trace.Assert(Boolean, String, String) usati con tre argomenti.

Debug.Assert ( stacksize > 100, "Out of stack space" , "Failed in inctemp" );
Trace.Assert ( stacksize > 0, "Out of stack space", "Failed in inctemp" );

Contenuto dell'argomento

Personalizzazione del comportamento di Assert

Se si esegue l'applicazione in modalità interfaccia utente, il Assert metodo visualizza la finestra di dialogo Asserzione non riuscita quando la condizione ha esito negativo. Le azioni che si verificano quando un'asserzione non riesce vengono controllate dalla Listeners proprietà o Listeners .

È possibile personalizzare il comportamento di output aggiungendo un TraceListener oggetto alla Listeners raccolta, rimuovendo un TraceListener oggetto dalla raccolta o eseguendo l'override Listeners del System.Diagnostics.TraceListener.Fail metodo di un oggetto esistente TraceListener per renderlo diverso.

Ad esempio, è possibile eseguire l'override del System.Diagnostics.TraceListener.Fail metodo per scrivere in un registro eventi anziché visualizzare la finestra di dialogo Asserzione non riuscita .

Per personalizzare l'output in questo modo, il programma deve contenere un listener ed è necessario ereditare da TraceListener ed eseguire l'override del relativo System.Diagnostics.TraceListener.Fail metodo.

Per ulteriori informazioni, vedere Listener di traccia.

Contenuto dell'argomento

Impostazione delle asserzioni nei file di configurazione

È possibile impostare asserzioni nel file di configurazione del programma e nel codice. Per altre informazioni, vedere System.Diagnostics.Trace.Assert o System.Diagnostics.Debug.Assert.

Contenuti correlati