Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Mithilfe einer Assertion oder einer Assert-Anweisung wird eine Bedingung überprüft, die Sie als Argument der Assert-Anweisung angeben. Wenn die Bedingung als "True" ausgewertet wird, erfolgt keine Aktion. Wenn die Bedingung auf "False" ausgewertet wird, schlägt die Assertion fehl. Wenn Sie das Programm mit einem Debugbuild erneut ausführen, wechselt es in den Unterbrechungsmodus.
In diesem Thema
Assertions im System.Diagnostics-Namespace
Nebenwirkungen von Debug.Assert
Verfolgungs- und Debuganforderungen
Anpassen des Assert-Verhaltens
Festlegen von Assertionen in Konfigurationsdateien
Assertions im System.Diagnostics-Namespace
In Visual Basic und Visual C# können Sie die Assert-Methode entweder von Debug oder Trace verwenden, die sich im System.Diagnostics-Namensraum befinden.
Debug Klassenmethoden sind nicht in einer Releaseversion Ihres Programms enthalten, sodass sie die Größe nicht erhöhen oder die Geschwindigkeit Des Releasecodes verringern.
C++ unterstützt die Debug Klassenmethoden nicht. Sie können den gleichen Effekt erzielen, indem Sie die Trace Klasse mit bedingter Kompilierung wie ... #ifdef DEBUG#endifverwenden.
Die Debug.Assert-Methode
Sie können die System.Diagnostics.Debug.Assert-Methode beliebig verwenden, um Bedingungen zu überprüfen, die bei fehlerfreiem Code "True" ergeben sollten. Angenommen, Sie haben eine Ganzzahltrennfunktion geschrieben. Gemäß den Regeln der Mathematik kann der Divisor niemals 0 sein. Sie können dies mit einer Assertion testen:
int IntegerDivide ( int dividend , int divisor )
{
Debug.Assert ( divisor != 0 );
return ( dividend / divisor );
}
Wenn Sie diesen Code unter dem Debugger ausführen, wird die Assertionsanweisung ausgewertet, aber in der Releaseversion wird der Vergleich nicht durchgeführt, sodass kein zusätzlicher Aufwand entsteht.
Hier ist ein weiteres Beispiel. Sie haben eine Klasse, die ein Girokonto implementiert, wie folgt:
float balance = savingsAccount.Balance;
Debug.Assert ( amount <= balance );
savingsAccount.Withdraw ( amount );
Bevor Sie Geld vom Konto abheben, sollten Sie sicherstellen, dass der Kontostand ausreicht, um den Betrag abzudecken, den Sie für die Auszahlung vorbereiten. Sie können eine Assertion schreiben, um den Saldo zu überprüfen:
float balance = savingsAccount.Balance;
Trace.Assert ( amount <= balance );
savingsAccount.Withdraw ( amount );
Beachten Sie, dass Aufrufe der System.Diagnostics.Debug.Assert Methode verschwinden, wenn Sie eine Releaseversion ihres Codes erstellen. Das bedeutet, dass der Aufruf, der den Saldo überprüft, in der Release-Version verschwindet. Um dieses Problem zu lösen, sollten Sie System.Diagnostics.Debug.Assert durch System.Diagnostics.Trace.Assert ersetzen, da es in der Release-Version nicht verschwindet.
Aufrufe von System.Diagnostics.Trace.Assert verursachen zusätzlichen Mehraufwand in Ihrer Release-Version, anders als Aufrufe von System.Diagnostics.Debug.Assert.
Nebenwirkungen von Debug.Assert
Stellen Sie bei der Verwendung von System.Diagnostics.Debug.Assert sicher, dass beliebiger Code innerhalb von Assert die Ergebnisse des Programms nicht ändert, wenn Assert es entfernt wird. Andernfalls können Sie versehentlich einen Fehler einführen, der nur in der Releaseversion Ihres Programms angezeigt wird. Achten Sie besonders auf Assertionsanweisungen, die Funktions- oder Prozeduraufrufe enthalten, wie in folgendem Beispiel:
Diese Verwendung von System.Diagnostics.Debug.Assert mag auf den ersten Blick sicher erscheinen, aber angenommen, die Funktion meas aktualisiert jedes Mal einen Zähler, wenn sie aufgerufen wird. Wenn Sie die Releaseversion erstellen, wird dieser Aufruf von Meas entfernt, sodass der Zähler nicht aktualisiert wird. Dies ist ein Beispiel für eine Funktion mit einem Nebeneffekt. Das Entfernen eines Aufrufs einer Funktion mit Nebenwirkungen kann zu einem Fehler führen, der nur in der Releaseversion angezeigt wird. Um solche Probleme zu vermeiden, platzieren Sie keine Funktionsaufrufe in einer System.Diagnostics.Debug.Assert Anweisung. Verwenden Sie stattdessen eine temporäre Variable:
Selbst wenn Sie System.Diagnostics.Trace.Assert verwenden, möchten Sie möglicherweise trotzdem vermeiden, Funktionsaufrufe innerhalb einer Assert-Anweisung zu platzieren. Solche Aufrufe sollten sicher sein, da System.Diagnostics.Trace.Assert Anweisungen in einem Release-Build nicht eliminiert werden. Wenn Sie solche Konstrukte jedoch aus Gewohnheit vermeiden, ist es weniger wahrscheinlich, dass Sie einen Fehler machen, wenn Sie System.Diagnostics.Debug.Assert verwenden.
Ablaufverfolgung- und Debugging-Anforderungen
Wenn Sie Ihr Projekt mithilfe der Visual Studio-Assistenten erstellen, wird das TRACE-Symbol standardmäßig sowohl in Release- als auch in Debugkonfigurationen definiert. Das DEBUG-Symbol ist standardmäßig nur im Debugbuild definiert.
Andernfalls muss Ihr Programm für Trace-Methoden eine der folgenden Voraussetzungen am Anfang der Quelldatei erfüllen:
#Const TRACE = Truein Visual Basic#define TRACEin Visual C# und C++Oder Ihr Programm muss mit der TRACE-Option erstellt werden:
/d:TRACE=Truein Visual Basic/d:TRACEin Visual C# und C++Wenn Sie die Debugmethoden in einem C#- oder Visual Basic Release-Build verwenden müssen, müssen Sie das DEBUG-Symbol in Ihrer Releasekonfiguration definieren.
C++ unterstützt die Debug Klassenmethoden nicht. Sie können den gleichen Effekt erzielen, indem Sie die Trace Klasse mit bedingter Kompilierung wie ...
#ifdef DEBUG#endifverwenden. Sie können diese Symbole im <Dialogfeld "Projekt-Eigenschaftenseiten>" definieren. Weitere Informationen finden Sie unter Ändern von Projekteinstellungen für eine Visual Basic-Debugkonfiguration oder ändern der Projekteinstellungen für eine C- oder C++-Debugkonfiguration.
Argumente validieren
System.Diagnostics.Trace.Assert und System.Diagnostics.Debug.Assert bis zu drei Argumente annehmen. Das erste Argument, das obligatorisch ist, ist die Bedingung, die Sie überprüfen möchten. Wenn Sie System.Diagnostics.Trace.Assert(Boolean) oder System.Diagnostics.Debug.Assert(Boolean) mit nur einem Argument aufrufen, überprüft die Methode Assert die Bedingung und gibt, falls das Ergebnis falsch ist, den Inhalt des Aufrufstapels im Ausgabefenster aus. Das folgende Beispiel zeigt System.Diagnostics.Trace.Assert(Boolean) und System.Diagnostics.Debug.Assert(Boolean):
Die zweiten und dritten Argumente müssen Zeichenfolgen sein, falls vorhanden. Wenn Sie System.Diagnostics.Trace.Assert oder System.Diagnostics.Debug.Assert mit zwei oder drei Argumenten aufrufen, ist das erste Argument eine Bedingung. Die Methode überprüft die Bedingung und gibt, wenn das Ergebnis falsch ist, die zweite Zeichenfolge und dritte Zeichenfolge aus. Das folgende Beispiel zeigt System.Diagnostics.Debug.Assert(Boolean, String) und System.Diagnostics.Trace.Assert(Boolean, String) wird mit zwei Argumenten verwendet:
Debug.Assert ( stacksize > 0, "Out of stack space" );
Trace.Assert ( stacksize > 0, "Out of stack space" );
Das folgende Beispiel zeigt System.Diagnostics.Debug.Assert(Boolean, String, String) und System.Diagnostics.Trace.Assert(Boolean, String, String) wird mit drei Argumenten verwendet:
Debug.Assert ( stacksize > 100, "Out of stack space" , "Failed in inctemp" );
Trace.Assert ( stacksize > 0, "Out of stack space", "Failed in inctemp" );
Anpassen des Assert-Verhaltens
Wenn Sie Ihre Anwendung im Benutzeroberflächenmodus ausführen, zeigt die Assert Methode das Dialogfeld Assertionsfehler an, wenn die Bedingung fehlschlägt. Die Aktionen, die ausgeführt werden, wenn eine Assertion fehlschlägt, werden von der Listeners oder Listeners Eigenschaft gesteuert.
Sie können das Ausgabeverhalten anpassen, indem Sie der Auflistung ein TraceListener-Objekt hinzufügen, ein Listeners-Objekt aus der TraceListener-Auflistung entfernen oder die Listeners-Methode eines vorhandenen System.Diagnostics.TraceListener.Fail-Objekts außer Kraft setzen, damit es sich anders verhält.
Beispielsweise können Sie die System.Diagnostics.TraceListener.Fail Methode außer Kraft setzen, um in ein Ereignisprotokoll zu schreiben, anstatt das Dialogfeld "Assertion fehlgeschlagen " anzuzeigen.
Um die Ausgabe auf diese Weise anzupassen, muss Ihr Programm einen Listener enthalten, und Sie müssen von TraceListener erben und seine System.Diagnostics.TraceListener.Fail Methode überschreiben.
Weitere Informationen finden Sie unter Ablaufverfolgungs-Listener.
Festlegen von Assertionen in Konfigurationsdateien
Sie können Assertionen in Ihrer Programmkonfigurationsdatei sowie in Ihrem Code festlegen. Weitere Informationen finden Sie unter System.Diagnostics.Trace.Assert oder System.Diagnostics.Debug.Assert.