[ Pobierz całość w formacie PDF ]

przerywają wykonywanie programu, możesz rozważyć zmodyfikowanie pro-
cedury asercji tak, aby jedynie rejestrowała komunikaty w pliku.
Dbaj o to, aby komunikaty były zrozumiałe i praktyczne. Gdy pozostawiasz
w programie wewnętrzne komunikaty błędów, zadbaj o to, aby były sformu-
łowane w języku czytelnym dla użytkownika. W toku jednego z pierwszych
w moim życiu projektów programistycznych zadzwonił do mnie użytkownik
z wiadomością, że wyświetlił się komunikat  Zła alokacja wskaz
nika, spadaj! .
Całe szczęście miał poczucie humoru. Popularnym i praktycznym podejściem
jest powiadomienie użytkownika o wystąpieniu  błędu wewnętrznego i zawar-
cie w komunikacie adresu e-mail lub numeru telefonu, pod którym można
zgłosić wystąpienie problemu.
8.8. Defensywne podejście
do programowania defensywnego
Nadmiar jest zawsze zły,
Nadmiar elementów programowania defensywnego może doprowadzić do
ale nadmiar whiskey
zupełnie nowych, specyficznych problemów. Jeżeli przekazywane za pomocą
jest w sam raz.
parametrów dane podlegają drobiazgowej kontroli w każdym możliwym miej-
 Mark Twain
scu, program staje się rozwlekły i powolny. Co gorsza, dodatkowy kod to zawsze
dodatkowa złożoność. Ponadto kod ten nie jest bardziej odporny na błędy niż
główny kod programu. W nim też mogą wystąpić błędy, a jest to tym bardziej
prawdopodobne, że najczęściej nie jest on pisany i rozwijany z równą uwagą
co podstawowy kod operacji. Zakres defensywnego programowania musi być
przemyślany  nadmiar jest równie szkodliwy jak niedostatek.
cc2e.com/0868
Lista kontrolna: Programowanie defensywne
Programowanie defensywne ogólnie
Czy procedura jest chroniona przed niepoprawnymi danymi wej-
ściowymi?
Czy użyłeś asercji do opisu przyjętych założeń, przede wszystkim
warunków wstępnych i końcowych?
8.8. Defensywne podejście do programowania defensywnego 247
Czy stosujesz asercje wyłącznie do opisywania sytuacji, które nigdy
nie powinny się zdarzyć?
Czy architektura lub projekt wysokiego poziomu wyznaczajÄ… okre-
ślony zbiór mechanizmów obsługi błędów, które powinny być
stosowane?
Czy architektura lub projekt wysokiego poziomu definiujÄ…, czy
obsługa błędów powinna być ukierunkowana na odporność, czy
na poprawność?
Czy wprowadziłeś między obszarami programu podziały zapew-
niające ograniczenie szkód powodowanych przez błędy i reduku-
jące ilość kodu, w którym niezbędne jest sprawdzanie poprawno-
ści danych?
Czy używałeś w programie kodu wspomagającego debugowanie?
Czy kod wspomagajÄ…cy debugowanie jest wprowadzany w taki spo-
sób, aby jego aktywowanie i dezaktywowanie nie było kłopotliwe?
Czy ilość kodu defensywnego jest odpowiednia  nie jest go za
dużo ani za mało?
Czy używałeś technik programowania ofensywnego, aby zabez-
pieczyć się przed przeoczeniem błędów?
WyjÄ…tki
Czy w projekcie określone zostało spójne podejście do stosowania
wyjątków?
Czy rozważyłeś alternatywy dla użycia wyjątku?
Czy lokalna obsługa błędów ma zawsze pierwszeństwo przed zgła-
szaniem nielokalnych wyjątków?
Czy unikasz zgłaszania wyjątków w konstruktorach i destruktorach?
Czy wszystkie wyjątki zostały dostosowane do poziomu abstrakcji
zgłaszających je procedur?
Czy dane wyjątków obejmują wszystkie potrzebne informacje?
Czy w kodzie nie ma pustych bloków catch? Jeżeli ich stosowanie
jest naprawdÄ™ uzasadnione, to czy kod zawiera odpowiednie wy-
jaśnienie?
Zabezpieczenia
Czy kod, który sprawdza dane wejściowe, próbuje wykrywać ata-
ki ukierunkowane na przepełnienie bufora, wstrzyknięcie kodu
SQL lub HTML, przepełnienie wartości całkowitych lub inne?
Czy sprawdzane są wyjściowe kody błędów procedur?
Czy wszystkie wyjÄ…tki sÄ… przechwytywane?
Czy komunikaty błędów nie zawierają informacji, które mogłyby
zostać wykorzystane przez osobę zainteresowaną włamaniem do
systemu?
248 Rozdział 8. Programowanie defensywne
Więcej informacji
cc2e.com/0875
W doskonaleniu umiejętności programowania defensywnego pomocne będą
następujące lektury:
Zabezpieczenia
Howard, Michael, i David LeBlanc. Writing Secure Code, 2nd Ed. Redmond,
WA, USA, Microsoft Press 2003. Howard i LeBlanc omawiają skutki, jakie może
mieć dla bezpieczeństwa systemów nadmierne zaufanie do danych wejściowych.
Książka otwiera oczy na świat niezliczonych możliwości przełamywania zabez-
pieczeń programów. Nie wszystkie, ale wiele z nich ma związek z metodami
programowania. Opis obejmuje pełne spektrum zagadnień związanych z wyma-
ganiami, projektowaniem, kodem i testami.
Asercje
Maguire, Steve. Writing Solid Code. Redmond, WA, USA, Microsoft Press 1993.
Rozdział 2. zawiera doskonałe omówienie tematu stosowania asercji ilustrowane
ciekawymi przykładami z dobrze znanych produktów firmy Microsoft.
Stroustrup, Bjarne. Język C++, Warszawa, WNT 2010. W punkcie 24.3.7.2 autor
opisuje kilka metod implementowania asercji w C++ i porusza temat zwiÄ…zku
między nimi a warunkami wstępnymi i końcowymi.
Meyer, Bertrand. Programowanie zorientowane obiektowo. Gliwice, Helion 2005.
Książka ta zawiera pełne omówienie tematu warunków wstępnych i końcowych.
WyjÄ…tki
Meyer, Bertrand. Programowanie zorientowane obiektowo. Gliwice, Helion 2005.
W rozdziale 12. znajduje się szczegółowe omówienie tematu wyjątków.
Stroustrup, Bjarne. Język C++, Warszawa, WNT 2010. W rozdziale 14. szczegó-
łowo omówiono mechanizm wyjątków języka C++. W podrozdziale 14.11 znaj-
duje się doskonałe zestawienie 21 porad dotyczących pracy z nimi.
Meyers, Scott. More Effective C++: 35 New Ways to Improve Your Programs and
Designs. Reading, MA, USA, Addison-Wesley 1996. Techniki o numerach od
9. do 15. to zarazem opis specyficznych cech mechanizmu wyjątków w C++.
Arnold, Ken, James Gosling i David Holmes. The Java Programming Language,
3rd Ed. Boston, MA, USA, Addison-Wesley 2000. W rozdziale 8. opisany został
mechanizm obsługi wyjątków w języku Java.
Bloch, Joshua. Effective Java Programming Language Guide. Boston, MA, USA,
Addison-Wesley 2001. W punktach od 39. do 47. opisywane sÄ… specyficzne
cechy mechanizmu wyjątków języka Java.
Podsumowanie 249
Foxall, James. Practical Standards for Microsoft Visual Basic .NET. Redmond, [ Pobierz całość w formacie PDF ]