niedziela, 27 kwietnia 2008

Kontrola błędów

Błąd popełnia każdy. A najczęściej użyszkodnik. Ciężko przewidzieć wszystkie możliwe działania tegoż osobnika. Im bardziej złożony program, tym więcej możliwości do zepsucia jego działania Między innymi dlatego tak długo trwają beta testy...no a przynajmniej powinny trwać.

Załóżmy, że mamy program, który zapisuje wynik swojego działania do pliku o określonej nazwie. Innymi słowy: jakiś edytor tekstu.
Pierwsze problemowe miejsce: wybór nazwy. Trzeba sprawdzić, czy:
1. Czy nazwa nie zawiera niedozwolonych znaków. Im gorszy system operacyjny (a raczej rodzaj partycji i system plików), tym więcej takich niedozwolonych znaków. Jeżeli program jest multiplatformowy, trzeba załączyć wszystkie możliwości.
Generalnie system operacyjny przy próbie "zuego" zapisu odmówi współpracy, ale po co użyszkodnik ma dostawać dziwne komunikaty? Lepiej, żeby program o tym poinformował w przyjazny sposób.
2. Czy podana nazwa jest unikatowa, czyli czy plik o podanej nazwie wcześniej nie istnieje. Jeżeli tak, to wyświetlić odpowiedni monit z prośbą o potwierdzenie nadpisania zawartości.
3. Czy użyszkodnik ma prawa do zapisu w danej lokalizacji? System znów zwróci błąd, ale sprawa jak w punkcie 1: trzeba przewidzieć jakiś stosowny komunikat.
4. Czy dany typ partycji może obsłużyć plik o zadanej objętości? Starsze partycje nie radzą sobie z plikami o jakiejś niebotycznej wielkości. Np FAT32 gubi się chyba przy 4GB.
5. Czy jest wystarczająca ilość pamięci operacyjnej, aby zapisać plik? Czy nie trzeba wyświetlić monitu z prośbą o zamknięcie zbyt wielu działających programów?
6. Czy inna aplikacja nie zapisuje/nie odczytuje w tym czasie danego pliku?
7. czy to? czy tamto?

A w końcu mówimy tylko o zapisie do pliku. Programy robią miliony innych rzeczy. Kontrola błędów jest też na podstawowym etapie wprowadzania danych. Najpierw sprawdza się czy dane wprowadzone przez usera są zgodne z maską, potem przekazuje głównej funkcji wykonawczej. W ten sposób dane trafiają do głównej funkcji w postaci zweryfikowanej. To znaczy - nie ma błędnych danych. Jeżeli funkcja jest zasobożerna, to dodanie do niej sprawdzania poprawności jeszcze bardziej obciąży procesor.

Z drugiej strony:
Nie trzeba na nowo wynajdywać koła. Istnieją odpowiednie zestawy funkcji, biblioteki programistyczne i podręczniki. Mimo wszystko, biedny programista musi się czasem wczuć się w rolę użyszkodnika i pomyśleć, co on może zepsuć. W końcu programy nie psułby się, gdyby nie ich użytkownicy, prawda?

Brak komentarzy: