Poinformowanie użytkownika końcowego o wyjątkach w WinForm-MVP i WPF-MVVM

Question

W ciągu pół roku od WinForm-MVP zaprojektowałem następującą strategię obsługi wyjątków. Mam podstawowej abstrakcyjnej klasy Presenter z kilkoma metodami Execute przyjmującymi delegata jako parametr wejściowy (sygnatury różnią się). Interakcja między View i Presenter odbywa się poprzez zdarzenia (dane wejściowe) zdefiniowane w IView oraz poprzez ustawienie właściwości publicznych (output) lub metod wywoływania zdefiniowanych w IView oraz implementowanych przez View. Każda procedura obsługi zdarzenia w prezencie wywołuje jedną z metod Execute, zapewniając jej konkretną realizację.

W metodzie wykonywania mam kilka bloków przechwytujących dla bardzo określonych wyjątków, które mogą wystąpić (głównie z powodu problemów z szeroko stosowanymi komponentami zewnętrznymi). Każdy z tych wyjątków zatrzymuje wykonywanie bieżącej operacji, jest rejestrowany i pokazywany użytkownikowi z sensownym wyjaśnieniem, wywołując metody View.

Nie tak dawno temu (w rzeczywistości BARDZO nie tak dawno temu) Zacząłem uczyć się WPF-MVVM, który od pierwszego spojrzenia wydaje się mieć wiele wspólnego z MVP. Szukałem tam kilku przydatnych wskazówek dotyczących strategii obsługi wyjątków (głównie informowanie użytkownika o problemach), ale na ogół trudno jest znaleźć to pytanie - mam na myśli, że wiele się mówi, ale głównie co do zasady. Znalazłem ponad 20 przykładów "obsługi" nieobsługiwanych wyjątków w pliku app.xaml.cs, wszystko jest bardzo miłe, ale powiedz mi szczerze - jeśli znasz dokładne wyjątki, które mogą spowodować awarię aplikacji, nie będziesz obsługiwać ich trochę wcześniej (nawet jeśli będziesz zmuszony zamknąć swoją aplikację)? Nie jestem zwolennikiem łapania wszystkich możliwych wyjątków. Sporo wyjątków spowodowanych problemami z siecią, chwilową niedostępnością bazy danych itp. Należy obsługiwać bez zamykania aplikacji bez przerażających ikon błędu, które dają zwykłemu użytkownikowi szansę powtórzenia jego żądania.

W ramach eksperymentu wypróbowałem prawie to samo, co opisałem wcześniej - Stworzyłem wydarzenia w ViewModel, aby przejść na wyjątki i zasubskrybować Wyświetl dla nich. Ale, szczerze mówiąc, ta droga daje mi gęsią skórkę.

(To była bardzo długa przemowa, wiem) Pytanie: jak sobie radzisz z wyjątkami dotyczącymi informowania użytkownika podczas korzystania z MVVM? Nie, na razie nie jestem zainteresowany weryfikacją danych. Mile widziany jest również wszelka krytyka i/lub porady dotyczące MVP.

Answer 1

Mamy kilka różnych strategii dla różnych rodzajów błędów w naszych aplikacjach Wpf.

Aby przewidzieć błędy, które kod może obsłużyć i kontynuować bez powiadamiania użytkownika, wykonujemy normalne bloki próbne.

W przypadku błędów, które są przewidywane, ale powodują awarię z punktu widzenia użytkownika, udostępniamy kolekcję powiadomień w naszych modelach ViewModels, związanych z ItemControl na naszej View, która jest szablonowana w podobny sposób do pasków powiadomień w Firefox/IE/Chrome.Każde powiadomienie ma właściwość trwania pokazu (zbiór powiadomień sam się oczyszcza za pomocą licznika czasu wysyłającego) i przycisk zamknięcia w widoku, dzięki czemu mogą pojawiać się przez określony czas lub mogą być jawnie zamknięte przez użytkownika. Zaletą tego modelu jest to, że można go używać do komunikatów, ostrzeżeń i wyjątków dotyczących ukończenia - a także do niektórych warunków, które mogą nie objawiać się jako wyjątek, ale nadal stanowią błędy z punktu widzenia użytkowników. Powiadomienia są często dobrym zamiennikiem okna komunikatu, ponieważ nie przerywają przepływu pracy użytkowników.

W przypadku błędów, których nie przewidujemy, używamy Red Gate SmartAssembly do przechwytywania wszystkich szczegółów, aby użytkownicy mogli przesłać je do naszego działu pomocy w celu analizy. Naszym zdaniem, przechwytywanie i kontynuowanie aplikacji po wyjątkach, których się nie spodziewałeś, to bardzo ryzykowna strategia - stos z nieoczekiwanego wyjątku nie jest rozwijany, a Twoja aplikacja pozostanie w niespójnym stanie po błędzie (co może skutkować wszystko od dziwnego interfejsu do uszkodzonych danych) i mogą wystąpić efekty niepożądane, których nie można przewidzieć. Nie jest to świetny sposób na awarię aplikacji, ale znacznie gorsze jest to, że dane są uszkodzone z powodu nieprzewidzianego stanu spowodowanego przez błąd, który został zignorowany przez aplikację. Naszą strategią jest uchwycenie jak największej liczby szczegółów dotyczących awarii, aby użytkownik wiedział, że poważnie podchodzimy do rozwiązania problemu, a my go naprawimy/złapiemy w przyszłej aktualizacji - zamiast po prostu kontynuować i zmierzyć się z potencjalnie gorszymi problemami.

Answer 2

Zgadzam się, pozostawiając obsługę wyjątków w Twojej app.xaml.cs nie jest dobra, ponieważ jest w zasadzie zbyt późno!

W przypadku operacji, w których potencjalny wyjątek jest względnie wysoki (obsługa plików, sieć IO), należy zapewnić aktywne wychwytywanie wyjątków. I wystawiać na widok na jeden z dwóch sposobów:

1. Dla błędów, które wskazują jakiś długotrwały problem, problemy z siecią na przykład I narazić „ErrorState” poperty
2. Dla przejściowych problemów, plik nie został znaleziony na przykład wystawiać wydarzenie.