[ Pobierz całość w formacie PDF ]
kroków: najpierw staramy się dla ogólnie znanego błędu zdefiniować możliwie szczegółowe
warunki jego wystąpienia, następnie całe zdarzenie sytuujemy wewnątrz określonej metody.
Istnieją dwa sposoby identyfikacji miejsca, w którym może pojawić się błąd. Albo zgodnie
z zasadami projektowania obiektowego dzielimy cały proces na metody i wskazujemy te, któ-
rych wywołanie może się nie powieść. Alternatywę stanowi podejście, w którym metody
definiujemy opierając się już na scenariuszu błędów. W ten sposób poszczególne operacje
przypisujemy określonym metodom, uwzględniając także granice wyznaczane przez obszary
ryzyka. Oba warianty są prawidłowe i mogą być na takich samych prawach stosowane pod-
czas pisania kodu aplikacji.
Zademonstruję teraz, w jaki sposób identyfikujemy miejsca potencjalnych błędów podczas
projektowania aplikacji. Przykładem będzie operacja tworzenie zamówienia i rezerwacja
towaru , wchodząca w skład przypadku użycia złożenie zamówienia . Jest to kluczowy etap
naszego procesu biznesowego. Na rysunku 6.4 widzimy szczegółowy diagram sekwencji, opi-
sujÄ…cy kolejne kroki zadania.
Rysunek 6.4. Diagram sekwencji procesu tworzenie zamówienia i rezerwacja towaru
Jeśli zestawisz ryzyko zidentyfikowane w poprzednim punkcie z zaprezentowanym diagramem,
możemy przyporządkować zdefiniowane tam błędy poszczególnym obiektom i związanym
z nimi akcjom.
R0zdział 6. Plan0wanie 0bsługi wyjątków 111
Lista potencjalnych zagrożeń operacji tworzenie zamówienia i rezerwacja towaru .
1. Czynności związane z obsługą bazy danych towarów:
zarządzanie połączeniem z bazą (metody i );
operacje na bazie danych ( ).
Uzyskanie połączenia z bazą za pomocą usługi katalogowej:
przeszukiwanie puli dostępnych połączeń;
obsługa połączenia (metody i ).
Konflikty związane z dostępem do zasobów w obiektach
i :
unikanie problemów związanych z pracą wielowątkową (metody
Kontrola transakcji w obiekcie :
obsługa transakcji w metodzie .
Etap drugi (czyli precyzyjny opis składników procesu), trzeci (identyfikacja potencjalnych
błędów) i prezentowany właśnie etap czwarty (wskazywanie miejsc wystąpienia tych błędów)
wykonywane mogą być wielokrotnie, za każdym razem zbliżając nas do momentu, w którym
cały proces będzie naprawdę dobrze przemyślany i zweryfikowany. Wtedy z czystym sumie-
niem przystąpić możemy do jego realizacji.
Etap 5. Przyg0t0wanie strategii 0bsługi błędów
Faza finałowa procesu polega na zaplanowaniu strategii obsługi każdego ewentualnego błędu,
który pojawi się podczas działania aplikacji. Możemy zastosować podejście ogólne opi-
sując po prostu sposób, w jaki powinniśmy zareagować. Z drugiej strony istnieje możliwość
stworzenia bardzo szczegółowego scenariusza, który określi kod obsługi błędu oraz sposób
zapisu informacji do dziennika. Obsługa wyjątków może mieć charakter jednopoziomowy,
ale możemy zdecydować się też na przesyłanie wyjątków do innych warstw aplikacji. W na-
szym przykładzie scenariusze te moglibyśmy naszkicować mniej więcej tak:
Strategie 0bsługi błędów dla 0peracji tw0rzenie zamówienia i rezerwacja t0waru
Klasa:
Metoda:
Ryzyko: Obsługa transakcji
Strategia: Przechwytujemy wyjątki zgłoszone wewnątrz metody. Gdy błąd jest
poważny, wycofujemy transakcję, zapisujemy informację o błędzie do dziennika,
przywracamy poprzedni stan aplikacji. W zależności od tego, jak implementacja
jest złożona, można rozważyć stworzenie osobnej metody służącej do wycofania
transakcji.
112 Część II Plan0wanie 0bsługi wyjątków
Ryzyko: Zakłócenie pracy wątku
Strategia: Unikajmy współdzielonych zmiennych odpowiadających za stan obiektu.
Jeśli są one nieodzowne, synchronizujmy dostęp do nich podczas tych operacji,
które wiążą się ze zmianą stanu.
Klasa:
Metoda:
Ryzyko: Zakłócenie pracy wątku
Strategia: Unikajmy współdzielonych zmiennych odpowiadających za stan obiektu.
Jeśli są one nieodzowne, synchronizujmy dostęp do nich podczas tych operacji,
które wiążą się ze zmianą stanu.
Klasa:
Metoda:
Ryzyko: Nieudana próba uzyskania połączenia z bazą danych
Strategia: Przekazujemy wyjątek na zewnątrz metody w celu przerwania całego
procesu (wycofanie transakcji nie jest konieczne). Rozważyć warto zachowanie
zamówienia i próbę przetwarzania w tle.
Metoda:
Ryzyko: Błąd zgłoszony przez bazę danych podczas rezerwacji towarów
Strategia: Przekazujemy wyjątek na zewnątrz metody w celu przerwania całego
procesu (tym razem należy wycofać transakcję). Rozważyć warto zachowanie
zamówienia i próbę przetwarzania w tle.
Metoda:
Ryzyko: Problemy związane z zakończeniem połączenia z bazą danych
[ Pobierz całość w formacie PDF ]