040

Chociaż dodawanie komentarzy o ograniczeniach zmiennych i innych warunkach jest bardzo ważne, to jednak należy uzupełniać je asercjami, aby się upewnić, że te warunki będą naprawdę spełnione. Czasami bowiem to co się dzieje w kodzie, nie odpowiada naszym oczekiwaniom. To jest właśnie definicja błędu -— program nie robi tego, czego oczekujemy (zobacz wskazówka 144.). Ponadto komentarz może przestać odpowiadać prawdzie. Załóżmy, że mamy komentarz mówiący: „Ta wartość na pewno nie będzie zbyt duża”. Cóż, to mogła być prawda, gdy zaczynaliśmy pisać program, ale jakaś zmiana mogła zdezaktualizować ten komentarz. Natomiast asercja zawsze będzie aktywna. Jeśli wprowadzamy asercję pilnującą, aby jakaś wartość nie była zbyt duża, to ostrzeżenie pojawi się zawsze wówczas, gdy wartość będzie zbyt duża, niezależnie od tego jak zmienimy kod.

Zauważmy, że asercje działają tylko w trakcie tworzenia kompilatów przeznaczonych do debugowania. Dzięki temu wszystkie korzyści ze stosowania asercji odnosimy podczas testowania, ale nie mają one wpływu na rozmiar programu lub wydajność ostatecznej wersji.

Przykład: SArray::QuickSort() w pliku bsrch.cpp

Obsługiwanie wyjątków nawet po użyciu asercji

unikanie awarii

Przed

assert(i < m_clMtabl); //Dalsza część programu

Po

assert(i < m_clMtabl); if (i < m_clMtabl)

{

//Dalsza część programu

Asercje są doskonałe. Jasno ostrzegają nas, gdy coś jest nie tak. A właściwie ostrzegają nas, gdy coś jest nie tak podczas debugowania. Dlatego też zawsze należy wstawiać je do kodu. Nie mogą jednak służyć unikaniu problemów, gdyż nie występują w ostatecznej wersji programu. Zawsze oprócz stosowania asercji trzeba obsługiwać kody błędów, tak aby w wypadku błędu uruchamiania program nie przerwał działania lub nie spowodował jakiejś awarii.

Przykład: SArray::QuickSort() w pliku bsrch.cpp