Obsługa błędów

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 :)

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.

Witam,

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

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.

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ę :)