032 TIF

linii i nie obchodzi nas, że jedna z nich może się już nie zmieścić, to wcale nie musimy sprawdzać kodu zwrotnego. W razie jakichś wątpliwości lepiej jednak zachować ostrożność.

Załóżmy, że przydziały pamięci nie powiodą się i że chcemy ustrzec nasz program przed takim wypadkiem. Dla zwiększenia wydajności warto podzielić kod na funkcje wymagające sprawdzenia argumentów oraz funkcje niewymagające takiego sprawdzania. Ponadto zawsze należy uzupełnić swoje założenia asercjami, tak na wszelki wypadek — nawet jeśli uważamy, że nie musimy sprawdzać parametrów.

Przykład: BF::FSetSize() w pliku bits.cpp

Uniemożliwianie dzielenia przez 0

unikanie awarii

Przed

nWyn = nLtcz / nMian;

Po

if (nMian)

nWyn = nLicz i nMian; else

//Podać tu jakiś wynik domyślny, nWyn = 0;

Przy dzieleniu przez zero zostaje wygenerowany błąd wykonania lub wyjątek. Zwykle ten błąd jest przekazywany do użytkownika tuż przed przerwaniem pracy programu. Przy każdym dzieleniu przez zmienną lub wartość obliczaną należy sprawdzać, czy nie jest to zero, aby uniknąć sytuacji, w której mianownik jest zerem.

Pojawienie się dzielenia przez zero może również wskazywać na złe wykonanie projektu. To również należy sprawdzić. Miejscowe poprawienie błędu mogłoby ukryć znacznie głębszy problem. Najpierw przekonajmy się, czy mianownik rzeczywiście mógł być zerem. (Czasem trzeba przy tym solidnie pogłówkować.) Dopiero wówczas, gdy nie spodziewamy się dzielenia przez zero, musimy dokładnie przeanalizować projekt. To może wymagać znacznie więcej pracy. Jeśli jednak mianownik po prostu może mieć wartość zerową, to wystarczy zabezpieczyć się przed tą sytuacją, tak jak w tym przykładzie.