Assertionen
Aktualisiert: November 2007
Dieses Thema gilt für folgende Anwendungsbereiche:
Edition |
Visual Basic |
C# |
C++ |
Web Developer |
|---|---|---|---|---|
Express |
.gif) |
|
Nur "Systemeigen" |
|
Standard |
|
|
Nur "Systemeigen" |
|
Pro und Team |
|
|
Nur "Systemeigen" |
|
Tabellenlegende:
.gif) |
Vorhanden |
|
Nicht vorhanden |
.gif) |
Befehl oder Befehle, die standardmäßig ausgeblendet sind. |
Eine Assertionsanweisung formuliert eine Bedingung, die an einer bestimmten Stelle im Programm true lauten muss. Hat diese Bedingung nicht den Wert true, schlägt die Assertion fehl, die Programmausführung wird unterbrochen, und das Dialogfeld "Assertionsfehler" wird geöffnet.
Visual C++ unterstützt Assertionsanweisungen, die auf folgenden Konstrukten basieren:
MFC-Assertionen für MFC-Programme.
ATLASSERT für Programme, die ATL verwenden.
CRT-Assertionen für Programme, die die C-Laufzeitbibliothek verwenden.
Die ANSI-assert-Funktion für andere C/C++‑Programme.
Assertionen bieten folgende Verwendungsmöglichkeiten:
Aufspüren von logischen Fehlern. Weitere Informationen finden Sie unter Aufspüren von logischen Fehlern.
Überprüfen der Ergebnisse einer Operation. Weitere Informationen finden Sie unter Ergebnisüberprüfung.
Testen auf Fehlerzustände, die bereits behandelt sein sollten. Weitere Informationen finden Sie unter Testen auf Fehlerzustände.
MFC- und C-Laufzeitbibliothek-Assertionen
Wenn der Debugger ein Programm aufgrund einer Assertion von MFC oder der C-Laufzeitbibliothek anhält, navigiert er zu der Stelle in der Quelldatei (sofern vorhanden), an der die Assertion aufgetreten ist. Die Assertionsmeldung wird sowohl im Ausgabefenster als auch im Dialogfeld Assertionsfehler angezeigt. Sie können die Assertionsmeldung aus dem Ausgabefenster in ein Textfenster kopieren, wenn Sie sie zu Referenzzwecken behalten möchten. Das Ausgabefenster enthält u. U. weitere Fehlermeldungen. Überprüfen Sie diese Meldungen sorgfältig; häufig enthalten sie Hinweise auf die Ursache des Assertionsfehlers.
Durch die großzügige Verwendung von Assertionen im Code können viele Fehler bereits während der Programmentwicklung beseitigt werden. Es empfiehlt sich, eine Assertion für jede Annahme zu schreiben. Wenn Sie beispielsweise annehmen, dass ein Argument ungleich NULL ist, überprüfen Sie diese Annahme mit einer Assertionsanweisung.
_DEBUG
Assertionsanweisungen werden nur kompiliert, wenn _DEBUG definiert ist. Andernfalls behandelt der Compiler Assertionen wie leere Anweisungen. Assertionsanweisungen verursachen daher keinen Mehraufwand in der endgültigen Programmversion. Sie können diese Anweisungen im Code uneingeschränkt verwenden, ohne die Leistung der Releaseversion zu beeinträchtigen und ohne dass #ifdef-Direktiven erforderlich wären.
Nebeneffekte der Verwendung von Assertionen
Wenn Sie Assertionen in den Code einfügen, sollten Sie sicherstellen, dass die Assertionen keine Nebeneffekte haben. Beachten Sie z. B. die folgenden Assertionen:
ASSERT(nM++ > 0); // Don't do this!
Da der ASSERT-Ausdruck in der Releaseversion des Programms nicht ausgewertet wird, verfügt nM in der Debug- und Releaseversion über unterschiedliche Werte. In MFC können Sie anstelle von ASSERT das VERIFY-Makro verwenden. Durch VERIFY wird der Ausdruck zwar ausgewertet, das Ergebnis jedoch in der Releaseversion nicht überprüft.
Da die Auswertung einer Funktion unerwartete Nebeneffekte haben kann, sollten Funktionsaufrufe in Assertionsanweisungen mit Vorsicht verwendet werden.
ASSERT ( myFnctn(0)==1 ) // unsafe if myFnctn has side effects
VERIFY ( myFnctn(0)==1 ) // safe
VERIFY ruft myFnctn sowohl in der Debug- als auch in der Releaseversion auf und kann somit verwendet werden. Der geringe Mehraufwand aufgrund eines unnötigen Funktionsaufrufs in der Releaseversion bleibt jedoch bestehen.
Siehe auch
Konzepte
Referenz
Assertionen in verwaltetem Code