Assertionen in verwaltetem Code
Aktualisiert: November 2007
Dieses Thema gilt für folgende Anwendungsbereiche:
Edition |
Visual Basic |
C# |
C++ |
Web Developer |
|---|---|---|---|---|
Express |
.gif) |
|
.gif) |
|
Standard |
|
|
|
|
Pro und Team |
|
|
|
|
Tabellenlegende:
|
Vorhanden |
|
Nicht vorhanden |
.gif) |
Befehl oder Befehle, die standardmäßig ausgeblendet sind. |
Mithilfe einer Assertion oder einer Assert-Anweisung wird eine Bedingung überprüft, die Sie als Argument der Assert-Anweisung angeben. Ergibt die Bedingung true, erfolgt keine Aktion. Wenn die Bedingung false ergibt, schlägt die Assertion fehl. Wenn das Programm mit einem Debugbuild ausgeführt wird, wechselt es in den Unterbrechungsmodus.
In Visual Basic und Visual C# können Sie die Assert.Methode sowohl aus Debug als auch aus Trace verwenden (beide befinden sich im System.Diagnostics-Namespace). Methoden der Debug-Klasse sind nicht in der Releaseversion des Programms enthalten. Sie erhöhen daher nicht den Umfang des Programms und beeinträchtigen nicht die Geschwindigkeit der Releaseversion.
C++ unterstützt nicht die Methoden der Debug-Klasse. Sie können dieselbe Wirkung durch die Verwendung der Trace-Klasse mit bedingter Kompilierung erzielen, z. B. #ifdef DEBUG... #endif.
Die Debug.Assert-Methode
Sie können die Debug.Assert-Methode beliebig verwenden, um den Code auf Bedingungen zu überprüfen, die bei fehlerfreiem Code true ergeben sollten. Angenommen, Sie haben eine Funktion zum Dividieren von ganzen Zahlen geschrieben. Gemäß den Regeln der Mathematik kann der Divisor niemals 0 sein. Sie könnten diese Bedingung mithilfe einer Assertion testen:
[Visual Basic]
Function IntegerDivide(ByVal dividend As Integer, ByVal divisor As Integer) As Integer
Debug.Assert(divisor <> 0)
Return CInt(dividend / divisor)
End Function
[C#]
int IntegerDivide ( int dividend , int divisor )
{ Debug.Assert ( divisor != 0 );
return ( dividend / divisor ); }
Wenn Sie diesen Code im Debugger ausführen, wird die Assertionsanweisung ausgewertet. In der Releaseversion findet der Vergleich jedoch nicht statt, sodass kein Mehraufwand entsteht.
Im Folgenden ein weiteres Beispiel. Sie verfügen über eine Klasse, die ein Girokonto wie folgt implementiert:
[Visual Basic]
Dim amount, balance As Double
balance = savingsAccount.balance
Debug.Assert(amount <= balance)
SavingsAccount.Withdraw(amount)
[C#]
float balance = savingsAccount.Balance;
Debug.Assert ( amount <= balance );
savingsAccount.Withdraw ( amount );
Bevor Sie Geld von diesem Konto abheben, möchten Sie sicherstellen, dass das Konto genügend Deckung für den abzuhebenden Betrag aufweist. Sie können eine Assertion schreiben, um den Saldo zu überprüfen:
[Visual Basic]
Dim amount, balance As Double
balance = savingsAccount.balance
Trace.Assert(amount <= balance)
SavingsAccount.Withdraw(amount)
[C#]
float balance = savingsAccount.Balance;
Trace.Assert ( amount <= balance );
savingsAccount.Withdraw ( amount );
Bedenken Sie, dass Aufrufe der Debug.Assert-Methode nicht mehr verfügbar sind, wenn Sie eine Releaseversion des Codes erstellen. Dies bedeutet, dass der Aufruf zum Überprüfen des Kontosaldos in der Releaseversion nicht mehr vorhanden ist. Um dieses Problem zu beheben, ersetzen Sie Debug.Assert durch Trace.Assert, denn diese Methode verschwindet in der Releaseversion nicht.
Aufrufe von Trace.Assert verursachen jedoch im Gegensatz zu Debug.Assert-Aufrufen in der Releaseversion einen zusätzlichen Aufwand.
Nebeneffekte von "Debug.Assert"
Stellen Sie bei Verwendung von Debug.Assert sicher, dass die Programmergebnisse nicht vom Code innerhalb von Assert abhängen, d. h. dass Assert ohne Auswirkungen entfernt werden kann. Dies kann ansonsten zu einem Fehler führen, der lediglich in der Releaseversion des Programms auftritt. Auch bei Assertionen, die Funktions- oder Prozeduraufrufe enthalten, sollte besonders sorgfältig vorgegangen werden. Siehe folgendes Beispiel:
[Visual Basic]
' unsafe code
Debug.Assert (meas(i) <> 0 )
[C#]
// unsafe code
Debug.Assert (meas(i) != 0 );
Diese Verwendung von Debug.Assert mag auf den ersten Blick sicher erscheinen. Was geschieht jedoch, wenn die Funktion meas bei jedem Aufruf einen Zähler aktualisiert? Wenn Sie die Releaseversion erstellen, wird dieser Aufruf von meas entfernt, sodass der Zähler nicht mehr aktualisiert wird. Dies ist ein Beispiel für eine Funktion mit einem Nebeneffekt. Durch das Entfernen eines Funktionsaufrufs, der Nebeneffekte hat, kann ein Fehler verursacht werden, der ausschließlich in der Releaseversion auftritt. Um derartige Probleme zu vermeiden, sollten Sie in eine Debug.Assert-Anweisung keine Funktionsaufrufe einfügen. Verwenden Sie stattdessen eine temporäre Variable.
[Visual Basic]
temp = meas( i )
Debug.Assert (temp <> 0)
[C#]
temp = meas( i );
Debug.Assert ( temp != 0 );
Auch wenn Sie Trace.Assert verwenden, möchten Sie möglicherweise Funktionsaufrufe innerhalb einer Assert-Anweisung vermeiden. Solche Aufrufe sollten kein Risiko darstellen, da Trace.Assert-Anweisungen nicht aus einem Releasebuild entfernt werden. Wenn Sie es sich jedoch zur Gewohnheit machen, solche Konstrukte zu vermeiden, können Sie Fehlern bei Verwendung von Debug.Assert vorbeugen.
Voraussetzungen für "Trace" und "Debug"
Wenn Sie das Projekt mithilfe der Visual Studio-Assistenten erstellen, wird das TRACE-Symbol sowohl in der Releasekonfiguration als auch in der Debugkonfiguration automatisch definiert. Das DEBUG-Symbol wird standardmäßig nur im Debugbuild definiert.
Andernfalls funktionieren Trace-Methoden nur dann, wenn an Anfang des Programms Folgendes steht:
#Const TRACE = True in Visual Basic
#define TRACE in Visual C# und C++
Oder das Programm muss mit der TRACE-Option erstellt werden:
/d:TRACE=True in Visual Basic
/d:TRACE in Visual C# und C++
Wenn Debug-Methoden in einem C#- oder Visual Basic-Releasebuild verwendet werden sollen, müssen Sie das DEBUG-Symbol in der Releasekonfiguration definieren.
C++ unterstützt nicht die Methoden der Debug-Klasse. Sie können dieselbe Wirkung durch die Verwendung der Trace-Klasse mit bedingter Kompilierung erzielen, z. B. #ifdef DEBUG... #endif. Diese Symbole können im Dialogfeld <Project>-Eigenschaftenseiten definiert werden. Weitere Informationen finden Sie unter Ändern von Projekteinstellungen für eine Visual Basic-Debugkonfiguration oder Ändern von Projekteinstellungen für eine C- oder C++-Debugkonfiguration.
Assert-Argumente
Trace.Assert und Debug.Assert nehmen bis zu drei Argumente an. Das erste Argument, das obligatorisch ist, bezieht sich auf die Bedingung, die überprüft werden soll. Bei einem Aufruf von Trace.Assert(Boolean) oder Debug.Assert(Boolean) mit nur einem Argument wird die Bedingung von der Assert-Methode überprüft. Wenn das Ergebnis false lautet, wird der Inhalt der Aufrufliste im Ausgabefenster angezeigt. Im folgenden Beispiel werden Trace.Assert(Boolean) und Debug.Assert(Boolean) veranschaulicht:
[Visual Basic]
Debug.Assert(stacksize > 0)
Trace.Assert(stacksize > 0)
[C#]
Debug.Assert ( stacksize > 0 );
Trace.Assert ( stacksize > 0 );
Beim zweiten und dritten Argument muss es sich, falls vorhanden, um Zeichenfolgen handeln. Wenn Sie Trace.Assert oder Debug.Assert mit zwei oder drei Argumenten aufrufen, ist das erste Argument eine Bedingung. Die Methode überprüft die Bedingung und gibt die als zweites und drittes Argument übergebenen Zeichenfolgen zurück, wenn das Ergebnis false lautet. Im folgenden Beispiel wird veranschaulicht, wie Debug.Assert(Boolean, String) und Trace.Assert(Boolean, String) mit zwei Argumenten verwendet werden.
[Visual Basic]
Debug.Assert(stacksize > 0, "Out of stack space")
Trace.Assert(stacksize > 0, "Out of stack space")
[C#]
Debug.Assert ( stacksize > 0, "Out of stack space" );
Trace.Assert ( stacksize > 0, "Out of stack space" );
Im folgenden Beispiel werden Assert und Assert veranschaulicht:
[Visual Basic]
Debug.Assert(stacksize > 0, "Out of stack space. Bytes left:" , Format(size, "G"))
Trace.Assert(stacksize > 0, "Out of stack space. Bytes left:" , Format(size, "G"))
Trace.Assert(stacksize > 0, "Out of stack space. Bytes left:", "inctemp failed on third call" )
[C#]
Debug.Assert ( stacksize > 100, "Out of stack space" , "Failed in inctemp" );
Trace.Assert ( stacksize > 0, "Out of stack space", "Failed in inctemp" );
Anpassen des Verhaltens von "Assert"
Wenn Sie die Anwendung im Benutzeroberflächen-Modus ausführen, wird durch die Assert-Methode das Dialogfeld Assertionsfehler angezeigt, sofern die Bedingung nicht erfüllt wird. Die Aktionen, die beim Fehlschlagen einer Assertion auszuführen sind, werden von der Listeners-Eigenschaft oder der Listeners-Eigenschaft gesteuert.
Das Ausgabeverhalten kann wie folgt angepasst werden: durch Hinzufügen eines TraceListener-Objekts zur Listeners-Auflistung, durch Entfernen eines TraceListener-Objekts aus der Listeners-Auflistung oder durch Überschreiben der TraceListener.Fail-Methode eines vorhandenen TraceListener-Objekts, um sein Verhalten zu ändern.
Sie können beispielsweise die TraceListener.Fail-Methode überschreiben, um die Ausgabe in ein Ereignisprotokoll zu schreiben, anstatt das Dialogfeld Assertionsfehler zu aktivieren.
Damit die Ausgabe auf diese Weise angepasst werden kann, muss das Programm über einen Listener verfügen, der von TraceListener erbt und dessen TraceListener.Fail-Methode überschrieben wird.
Weitere Informationen finden Sie unter Ablaufverfolgungslistener.
Festlegen von Assertionen in Konfigurationsdateien
Sie können Assertionen sowohl in der Programmkonfigurationsdatei als auch im Code festlegen. Weitere Informationen hierzu finden Sie unter Trace.Assert oder Debug.Assert.
Siehe auch
Aufgaben
Gewusst wie: Bedingtes Kompilieren mit Ablaufverfolgung und Debuggen
Konzepte
Referenz
Weitere Ressourcen
Ablaufverfolgung und Instrumentieren von Anwendungen
Vorbereitung zum Debugging: C#- und Visual Basic-Projekttypen