Kiedy należy pozwolić aplikacji na awarię z powodu wyjątku w języku Java (problem z projektowaniem)?

Question

W większości przypadków możliwe jest przechwytywanie wyjątków w Javie, nawet niezaznaczonych. Ale niekoniecznie można coś z tym zrobić (na przykład z pamięci).

W innych przypadkach problem, który próbuję rozwiązać, jest zasadą jednego projektu. Próbuję ustanowić zasadę projektowania lub zbiór zasad wskazujących, kiedy należy zrezygnować z wyjątkowej sytuacji, nawet jeśli zostanie ona wykryta na czas. Celem jest nie załamanie aplikacji w jak największym stopniu.

Czy ktoś już burzy mózgów i komunikował się o tym? Szukam konkretnych ogólnych przypadków i możliwych rozwiązań lub reguł kciuka.

UPDATE

Sugestie dotąd:

• przestanie działać jeśli spójność danych może być zagrożona
• stop działa, jeśli dane mogą zostać usunięte
• stop działa, jeśli nie można zrobić cokolwiek na ten temat (Brak pamięci ...)

• Zatrzymaj działanie, jeśli kluczowa usługa nie jest dostępna lub zostanie otwarta mes niedostępny i nie może być wznowiona

• Metoda/usługa powinna sprawdzić, czy może on wykonywać swoje obowiązki ze stabilnym stanie, jeśli nie powinien poinformować użytkownika (log) i nic nie robić

• Jeśli aplikacja musi zostać zatrzymany , degradują jak wdzięcznie jako możliwe
• użytkowania cofanie w transakcjach db
• Indywidualne wyjątki mogą być stosowane, aby dać wskazówki, jak rozwiązać sytuację obsługi
• Log tyle istotnych informacji, jak można
• Zawiadom deweloperów

• zachowania stanu i spójności danych, jak tylko może

• Szybkie poprawki mogą być szkodliwe, gdy debugowanie, lepiej niech crash aplikacji i analizować szczegółowo, co spowodowało jej

Answer 1

Dlaczego i kiedy pozwolić katastrofie aplikacja nie ma szczególnych zasad ...... i niech moja ruina wniosek o następujących powodów:

1. Szybkie poprawki mogą kick-z powrotem i są Poten ryzykowne. NIE uważam za właściwe naprawiać błędu, nie wiedząc, jaki był faktyczny powód awarii mojego kodu. Dopuszczenie awarii aplikacji prowadzi mnie do błędu w moim kodzie.

2. Pozwalanie na awarię kodu pomaga lepiej zrozumieć język programowania i błędy logiczne.

To mój powód pozwalając awarii aplikacji ..

Answer 2

Twórcy Java i.Net zdecydował się użyć TYPE wyrzuconego obiektu wyjątku, aby określić, kiedy należy go złapać i kiedy należy go uznać za rozwiązany, decyzja projektowa prawdopodobnie jest motywowana przez sposób, w jaki C++ obsługuje wyjątki. Chociaż obsługa wyjątków C++ była pod wieloma względami ulepszeniem tego, co istniało wcześniej, to użycie tego typu obiektu wyjątku jako podstawowego środka do określenia, które wyjątki zostały przechwycone, nie było jedną z jego lepszych funkcji.

Ponieważ przechwytywanie wyjątków jest kontrolowane przez typ wyjątku, nie ma standardowych środków dla wyjątku, aby wskazać, czy operacja, której się nie powiodła, zmieniła stan jakichkolwiek obiektów w systemie, lub czy awaria została spowodowana przez obiekty będące w stanie uszkodzonym (w przeciwieństwie do stanu, który może być nieoczekiwany przez osobę dzwoniącą i nie jest zgodny z parametrami przekazywanymi, w przeciwnym wypadku zostanie uznany za wskazany sposób, aby był całkowicie zgodny z prawem). W wielu przypadkach, jeśli w odpowiedzi na żądanie użytkownika system wywołuje metodę, która próbuje coś zrobić i nie może, ale metoda nie wpływa niekorzystnie na stan dowolnego obiektu, a problem nie jest spowodowany przez obiekt mający uszkodzony stan, często najlepiej jest po prostu poinformować użytkownika, że ​​żądane działanie nie może być wykonane i kontynuować. Niestety, nie ma sposobu na odróżnienie "nieszkodliwych" wyjątków typów wskazanych powyżej, od tych, które wskazują na poważne problemy ogólnosystemowe. O ile 99% wyjątków będzie prawdopodobnie stosunkowo nieszkodliwych, niewielka część będzie spowodowana warunkami, które mogą powodować korupcję w otwieraniu dokumentów. Jeśli otwarty dokument został uszkodzony, może być lepiej, aby program natychmiast się zawiesił, niż pozwolił mu zastąpić dobrą kopię na dysku uszkodzoną.

W przypadku wyrzucania niestandardowych wyjątków możliwe może być uwzględnienie właściwości w typie wyjątku, który pozwoliłby kodowi na bardziej użyteczne decydowanie o tym, co należy zrobić z wyjątkiem. Niestety, wiele wyjątków, które zostaną rzucone, czy nieszkodliwe czy nie, nie będzie zawierało takich właściwości.

Answer 3

Awaria aplikacji to coś, co zależy od krytycznego poziomu aplikacji i architektury wdrażania.

Przykładowo aplikacja nie powinna ulegać awarii, jeśli kontroluje rakietę z ziemi (z wyjątkiem sytuacji niemożliwych do kontrolowania i priorytetów danych).

Podczas projektowania aplikacji należy je zaprojektować tak, aby żadne dane w magazynach danych nie były usuwane ani zmieniane.

Podsumowując, nie ma twardego i szybkiego sposobu określania reguł, kiedy aplikacje powinny się zawiesić.