Udostępnij za pośrednictwem

Asercji w kodzie zarządzanym

Potwierdzenie (lub instrukcja Assert) testuje warunek, który określasz jako argument instrukcji Assert. Jeśli warunek ma wartość „true” (prawda), nie są wykonywane żadne akcje. Jeśli warunek ma wartość „false” (fałsz), asercja kończy się niepowodzeniem. Jeśli używasz wersji debugowej, program przechodzi w tryb debugowania.

W tym temacie

Asercje w przestrzeni nazw System.Diagnostics

Metoda Debug.Assert

Skutki uboczne Debug.Assert

Wymagania dotyczące śledzenia i debugowania

Argumenty asertywne

Dostosowywanie zachowania asertywnego

Ustawianie asercji w plikach konfiguracji

Asercje w przestrzeni nazw System.Diagnostics

W programach Visual Basic i Visual C# można używać metody Assert zarówno z Debug, jak i z Trace, które znajdują się w przestrzeni nazw System.Diagnostics. Debug Metody klas nie są uwzględniane w wersji produkcyjnej programu, więc nie zwiększają jego rozmiaru ani nie zmniejszają szybkości kodu produkcyjnego.

Język C++ nie obsługuje Debug metod klas. Ten sam efekt można osiągnąć za pomocą Trace klasy z kompilacją warunkową, taką jak #ifdef DEBUG... #endif.

W tym temacie

Metoda Debug.Assert

Użyj metody System.Diagnostics.Debug.Assert swobodnie, aby przetestować warunki, które powinny być prawdziwe, jeśli kod jest poprawny. Załóżmy na przykład, że utworzono funkcję dzielenia liczb całkowitych. Zgodnie z zasadami matematyki podział nigdy nie może być zerowy. Możesz to przetestować przy użyciu asercji:

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

Po uruchomieniu tego kodu w debugerze instrukcja asercji jest sprawdzana, ale w wersji produkcyjnej porównanie nie jest wykonywane, więc nie ma dodatkowego obciążenia.

Oto kolejny przykład. Masz klasę, która implementuje rachunek bieżący w następujący sposób:

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

Przed wycofaniem pieniędzy z konta chcesz upewnić się, że saldo konta jest wystarczające do pokrycia kwoty, którą przygotowujesz do wycofania. Możesz napisać asercję w celu sprawdzenia salda:

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

Pamiętaj, że wywołania metody System.Diagnostics.Debug.Assert znikają, gdy tworzysz wersję Release swojego kodu. Oznacza to, że wywołanie sprawdzające saldo zniknie w wersji finalnej. Aby rozwiązać ten problem, należy zastąpić System.Diagnostics.Debug.Assert z System.Diagnostics.Trace.Assert, który nie znika w wersji wydania:

Wywołania do System.Diagnostics.Trace.Assert powodują obciążenie wersji Release, w odróżnieniu od wywołań do System.Diagnostics.Debug.Assert.

W tym temacie

Skutki uboczne Debug.Assert

Jeśli używasz polecenia System.Diagnostics.Debug.Assert, upewnij się, że żaden kod wewnątrz Assert programu nie zmienia wyników programu, jeśli Assert zostanie usunięty. W przeciwnym razie możesz przypadkowo wprowadzić usterkę, która jest wyświetlana tylko w wersji wydania programu. Należy zachować szczególną ostrożność w przypadku asertów zawierających wywołania funkcji lub procedury, na przykład w poniższym przykładzie:

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

To użycie System.Diagnostics.Debug.Assert może wydawać się bezpieczne na pierwszy rzut oka, ale załóżmy, że funkcja meas za każdym razem, gdy jest wywoływana, aktualizuje licznik. Po utworzeniu wersji wydania wywołanie meas zostanie wyeliminowane, więc licznik nie zostanie zaktualizowany. Jest to przykład funkcji z efektem ubocznym. Wyeliminowanie wywołania funkcji, która ma skutki uboczne, może spowodować usterkę, która pojawia się tylko w wersji wydania. Aby uniknąć takich problemów, nie umieszczaj wywołań funkcji w instrukcji System.Diagnostics.Debug.Assert . Zamiast tego użyj zmiennej tymczasowej:

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

Nawet jeśli używasz metody System.Diagnostics.Trace.Assert, nadal możesz unikać umieszczania wywołań funkcji wewnątrz instrukcji Assert . Takie wywołania powinny być bezpieczne, ponieważ System.Diagnostics.Trace.Assert wyrażenia nie są usuwane w kompilacji Release. Jeśli jednak unikasz takich konstrukcji z przyzwyczajenia, jest mniej prawdopodobne, że popełnisz błąd, gdy używasz System.Diagnostics.Debug.Assert.

W tym temacie

Wymagania dotyczące śledzenia i debugowania

Jeśli tworzysz projekt przy użyciu kreatorów programu Visual Studio, symbol TRACE jest domyślnie definiowany zarówno w konfiguracjach Release, jak i Debug. Symbol DEBUG jest definiowany domyślnie tylko w kompilacji Debug.

W przeciwnym razie, aby Trace metody działały, program musi mieć jeden z następujących elementów w górnej części pliku źródłowego:

Weryfikacja argumentów

System.Diagnostics.Trace.Assert i System.Diagnostics.Debug.Assert przyjmują do trzech argumentów. Pierwszy argument, który jest obowiązkowy, to warunek, który chcesz sprawdzić. Jeśli wywołasz System.Diagnostics.Trace.Assert(Boolean) lub System.Diagnostics.Debug.Assert(Boolean) z tylko jednym argumentem, metoda Assert sprawdzi warunek i, jeśli wynik jest fałszywy, zapisze zawartość stosu wywołań w oknie Dane wyjściowe. W poniższym przykładzie pokazano System.Diagnostics.Trace.Assert(Boolean) i System.Diagnostics.Debug.Assert(Boolean):

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

Drugi i trzeci argument, jeśli istnieją, muszą być ciągami. Jeśli wywołasz System.Diagnostics.Trace.Assert lub System.Diagnostics.Debug.Assert z dwoma lub trzema argumentami, pierwszym argumentem jest warunek. Metoda sprawdza warunek i, jeśli wynik ma wartość false, zwraca drugi ciąg i trzecie ciągi. W poniższym przykładzie pokazano, jak System.Diagnostics.Debug.Assert(Boolean, String) i System.Diagnostics.Trace.Assert(Boolean, String) są używane z dwoma argumentami.

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

W poniższym przykładzie pokazano System.Diagnostics.Debug.Assert(Boolean, String, String) i System.Diagnostics.Trace.Assert(Boolean, String, String) z użyciem trzech argumentów.

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

W tym temacie

Dostosowywanie zachowania metody assert

Jeśli uruchomisz aplikację w trybie interfejsu użytkownika, metoda Assert wyświetli okno dialogowe Assertion Failed, gdy warunek zakończy się niepowodzeniem. Akcje, które występują, gdy asercja kończy się niepowodzeniem, są kontrolowane przez właściwość Listeners lub Listeners.

Zachowanie danych wyjściowych można dostosować, dodając TraceListener obiekt do Listeners kolekcji, usuwając obiekt TraceListener z Listeners kolekcji lub przez zastąpienie System.Diagnostics.TraceListener.Fail metody istniejącej TraceListener , aby zachowywała się inaczej.

Można na przykład nadpisać metodę System.Diagnostics.TraceListener.Fail w celu zapisania w dzienniku zdarzeń, zamiast wyświetlić okno dialogowe Błąd asercji.

Aby dostosować dane wyjściowe w ten sposób, program musi zawierać odbiornik i należy dziedziczyć TraceListener i zastąpić jego System.Diagnostics.TraceListener.Fail metodę.

Aby uzyskać więcej informacji, zobacz Śledzenie odbiorników.

W tym temacie

Ustawianie asercji w plikach konfiguracji

Asercji można ustawić w pliku konfiguracji programu, a także w kodzie. Aby uzyskać więcej informacji, zobacz System.Diagnostics.Trace.Assert lub System.Diagnostics.Debug.Assert.

Treści powiązane