MFC ASSERT_VALID und "CObject::AssertValid"

Dieses Thema gilt für folgende Anwendungsbereiche:

Edition	Visual Basic	C#	F#	C++	Web Developer
Express				Nur "Systemeigen"
Pro, Premium und Ultimate				Nur "Systemeigen"

Die CObject::AssertValid-Methode ermöglicht es, den internen Zustand eines Objekts zur Laufzeit zu überprüfen. Es ist zwar nicht erforderlich, AssertValidbeim Ableiten der Klasse aus CObject zu überschreiben, Sie können so jedoch die Zuverlässigkeit der Klasse erhöhen. AssertValid sollte Assertionen für alle Membervariablen des Objekts ausführen und sicherstellen, dass diese gültige Werte enthalten. Beispielsweise sollte überprüft werden, ob alle Membervariablen in Form von Zeigern ungleich NULL sind.

Im folgenden Beispiel wird die Deklaration einer AssertValid-Funktion erläutert:

class CPerson : public CObject
{
protected:
    CString m_strName;
    float   m_salary;
public:
#ifdef _DEBUG
    // Override
    virtual void AssertValid() const;
#endif
    // ...
};

Wenn Sie AssertValid überschreiben, rufen Sie die Basisklassenversion von AssertValid auf, bevor Sie eigene Überprüfungen vornehmen. Überprüfen Sie dann mit dem ASSERT-Makro wie folgt die Gültigkeit der Member, die nur in der abgeleiteten Klasse vorkommen:

#ifdef _DEBUG
void CPerson::AssertValid() const
{
    // Call inherited AssertValid first.
    CObject::AssertValid();

    // Check CPerson members...
    // Must have a name.
    ASSERT( !m_strName.IsEmpty());
    // Must have an income.
    ASSERT( m_salary > 0 );
}
#endif

Wenn durch eine der Membervariablen Objekte gespeichert werden, können Sie deren interne Gültigkeit mit dem ASSERT_VALID-Makro testen (falls die betreffende Klasse AssertValid überschreibt).

Durch die CMyData-Klasse wird beispielsweise CObList in einer ihrer Membervariablen gespeichert. Die CObList-Variable m_DataList speichert eine Auflistung von CPerson-Objekten. Die Deklaration von CMyData lautet in den wesentlichen Teilen wie folgt:

class CMyData : public CObject
{
    // Constructor and other members ...
    protected:
        CObList* m_pDataList;
    // Other declarations ...
    public:
#ifdef _DEBUG
        // Override:
        virtual void AssertValid( ) const;
#endif
    // And so on ...
};

Die AssertValid-Überschreibung in CMyData sieht wie folgt aus:

#ifdef _DEBUG
void CMyData::AssertValid( ) const
{
    // Call inherited AssertValid.
    CObject::AssertValid( );
    // Check validity of CMyData members.
    ASSERT_VALID( m_pDataList );
    // ...
}
#endif

CMyData verwendet den AssertValid-Mechanismus, um die Gültigkeit der in ihrem Datenmember gespeicherten Objekte zu testen. Durch das AssertValid-Überschreiben von CMyData wird das ASSERT_VALID-Makro für die eigene m_pDataList-Membervariable aufgerufen.

Die Gültigkeitsüberprüfung wird auf dieser Ebene nicht beendet, da AssertValid auch von CObList überschrieben wird. Diese Überschreibung bewirkt weitere Gültigkeitsüberprüfungen des internen Listenzustands. Auf diese Weise führt eine Gültigkeitsüberprüfung für ein CMyData-Objekt zu weiteren Gültigkeitsüberprüfungen, mit denen der interne Zustand des gespeicherten CObList-Listenobjekts getestet wird.

Mit geringem Mehraufwand könnten die Gültigkeitsüberprüfungen auch auf die in der Liste gespeicherten CPerson-Objekte ausgeweitet werden. Sie könnten eine CPersonList-Klasse von CObList ableiten und AssertValid überschreiben. Hierbei würden Sie CObject::AssertValid aufrufen und dann die Liste durchlaufen, wobei für jedes in der Liste gespeicherte CPerson-Objekt AssertValid aufgerufen würde. Durch die am Anfang dieses Themas dargestellte CPerson-Klasse wird AssertValid bereits überschrieben.

Dieses Verfahren ist beim Erstellen von Debugbuilds äußerst hilfreich. Beim späteren Erstellen eines Releasebuilds wird das Verfahren automatisch deaktiviert.

Einschränkungen von "AssertValid"

Benutzer einer AssertValid-Funktion einer bestimmten Klasse sollten sich der einschränkenden Wirkung dieser Funktion bewusst sein. Eine ausgelöste Assertion weist darauf hin, dass das Objekt mit Sicherheit fehlerhaft ist, und die Ausführung wird angehalten. Wird keine Assertion ausgelöst, so bedeutet dies jedoch nur, dass kein Problem festgestellt wurde, die Fehlerfreiheit des Objekts kann aber trotzdem nicht garantiert werden.

Siehe auch

Konzepte

MFC-Assertionen