Obsługa błędów

Odpowiedz Nowy wątek
2009-10-27 10:34

Rejestracja: 10 lat temu

Ostatnio: 8 lat temu

0

Witam serdecznie,
mam mały dylemat. Otóż tworze aplikację opartą o jakieś źródło danych (nie ma powiedziane, czy jest to baza danych, czy też plik xml).
Z tego też powodu podzieliłem aplikację na 3 projekty.

  • Główny (zawiera klasy wykorzystywane w dwóch pozostałych projektach)
  • Dostępu do danych
  • Wizualizacja

Stworzyłem sobie interfejs providera danych, który jest implementowany przez różne inne klasy, ma on metody w stylu Create, Read, Delete itd.

I teraz mam taki mały problem, w jaki sposób obsługiwać błędy. Powiedzmy, że w jakimś providerze danych znajdującym się w projekcie Dostępu do danych wyskoczy mi wyjątek. Wiąże się to bardzo często z wyświetleniem okienka dialogowego z jakąś informacją typu: brak dostępu do bazy danych, lub podany plik nie istnieje. Nie chce tego robić w klasie provider'a bo ona jakby patrzeć nie służy wizualizacji w żaden sposób.

Załóżmy taki scenariusz: po kliknięciu przycisku Load, wywoływana jest metoda LoadData klasy zarządzającej jakimiś obiektami (z projektu Głównego), LoadData wywołuje metode Read provider'a(projekt dostępu do danych), a tam wyrzucany jest wyjątek, że nie można połączyć się z bazą danych.

Wpadłem na pomysł kaskadowego wyrzucania wyjątków, tzn. po złapaniu wyjątku wyrzucić go jeszcze raz.
I tak aż dojdziemy do warstwy prezentacji, ale nie wiem czy to dobre rozwiązanie.

Jestem bardzo ciekaw, jak Wy rozwiązujecie takie problemy. Jeżeli za słabo nakreśliłem problem, proszę o informację wtedy postaram się go lepiej opisać :)

Pozdrawiam serdecznie,
whill3r :)

Pozostało 580 znaków

2009-10-27 15:29

Rejestracja: 11 lat temu

Ostatnio: 9 lat temu

0

Witam

Stosuję opisany przez Ciebie sposób i także jestem ciekaw, czy to odpowiednie rozwiązanie, tak więc podłączam się do pytania.

Pozostało 580 znaków

2009-10-27 15:55
Moderator

Rejestracja: 12 lat temu

Ostatnio: 3 godziny temu

Lokalizacja: Wrocław

0

Witam,

Stosuję sposób taki, jak Wy, ale także nie wiem, czy to prawidłowe rozwiązanie, zatem przyłączam się do pytania.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2009-10-27 17:43

Rejestracja: 14 lat temu

Ostatnio: 8 lat temu

0

Ja preferuje zdefiniowanie jednego/kilku typow wyjatku, np. DataSourceProviderException i opakowywanie tego co polecialo w ten wyjatek. Do tego mozna dolozyc typ wyjatku, np. Fatal, Warning, itp, flage czy komunikat jest UserFriendly i inne. Takie rozwiazanie przede wszystkim pozwala na:

  • lapanie konkretnego wyjateku, a nie np. Exception (bo nie wiadomo co wlasciwie sie stalo).
  • rozpoznanie czy z czystym sercem wyswietlamy komunikat z wyjatku, czy dajemy ogolnie brzmiace, ale strawne dla uzytkownika "Nastapil blad, skontaktuj sie z ..."
  • brak kaskadowego przerzucania sie wyjatkami w kazdej mozliwej metodzie, ktora ma cokolwiek wspolnego z pobraniem danych

Oprocz tego taki wyjatek w miejscu obslugi/wizualizacji logujemy sobie gdzies, uzytkownikowi wyswietlamy komunikat, np. z tokenem, a pozniej przegladamy sobie logi, szukajac jego tokena i patrzymy konkretnie co sie stalo - bo mamy wyjatek z pelnym stack tracem, wyjatkiem wewnetrznym itp.


You need to learn how to walk
before you can run

Pozostało 580 znaków

2009-10-27 20:18

Rejestracja: 10 lat temu

Ostatnio: 8 lat temu

0

Poczytałem troszkę i metoda o której mówimy ma nazwę "bubbling up exceptions". Do poczytania więcej na Google :)
Jednocześnie natrafiłem na dość ciekawy artykuł http://msdn.microsoft.com/en-us/magazine/cc164003.aspx który opisuje sposób przedstawiony przez johnny'ego (dodatkowo implementacja własnego call stacka :)) I to chyba jest najlepsze rozwiązanie. Faktycznie lepiej jest łapać wyżej jeden wyjątek, niż powielać cały czas bloki catch.

Jutro przerabiam pod ten sposób swoją aplikację :)

Pozostało 580 znaków

Odpowiedz

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0