Zastanawiam się nad obsługą błędów w javie. W niektórych miejscach mojego programu mogą wystąpić wyjątki np NumberFormat itd. i tutaj nie mam problemu z obsłużeniem. Ale co zrobić, gdy np wiem, że dana jest niepoprawna (np String ma zła wartość) jaki wtedy rzucać wyjątek? new Exception, czy stworzyć nowa klasę rozszerzającą Exception?
Czy są jakieś zasady dla definiowania wlasnych bledów?
0
0
IMO zawsze (no prawie) warto definiować swoje wyjątki.
0
Hm... zanim wyrzucisz wyjątek zastanów się czy nie można rozwiązać problemu w inny sposób. Podałeś jako przykład NumberFormatException. Przecież tego wyjątku można łatwo uniknąć przeprowadzając walidację podanego ciągu znaków. Bardzo złą praktyką jest wykorzystywanie wyjątków do sterowania przepływem danych i sterowania pomiędzy klasami. Specyfika Javy tzn. przymus obsługi wyjątków innych niż RuntimmeException, powoduje iż kod sterowany wyjątkami staje się bardzo powolny. Każdy blok try/catch spowalnia kod o mniej więcej jeden rząd wielkości. Tym samym nawet mały i zdawać by się mogło prosty program może działać strasznie powoli.
0
Zawsze da się obyć bez wyjątków (np. tak jak w C). To chyba, nie jest dobry trop.
Wyjątki faktycznie spowolnią działanie programu (wychodzi im to niezwykle dobrze), ale tylko w przypadku, gdy są wykorzystywane do sterowania przebiegiem programu, zwracania wyniku etc. Testowałem to jakiś czas temu.
W praktyce, jeżeli występuje gdzieś w programie błąd to zazwyczaj jest on wykrywany w metodzie, która nie wie jak sobie z tym proradzić (np. pierwiastek z liczby ujemnej). Wtedy jedynym dobrym rozwiązaniem jest wyjątek.
IMO skoro w jakiejś metodzie ma niepoprawny arg. typu string to należy rzucić wyjątek (najlepiej swój).
0
@lmmilewski, ale wyjątek nie powinien służyć do obsługiwania sytuacji "prawdopodobnych" jakimi są np. błędnie wprowadzone dane. Takie problemy można, a wręcz należy rozwiązywać "polubownie" za pomocą np. komunikatów.
0
Nie rozumiem trochę tego rozumowania. Każda sytuacja jest prawdopodobna.
Jak ktoś czyta plik to raczej nie użyje wyjątku do spr. czy plik się skończył.
Być może źle Cię rozumiem. W którym momencie wiesz, że dane były błędne (pomijając takie głupoty jak string zamiast int'a etc.)?
Wydaje mi się, że nie w warstwie interfejsu.
Pewnie też nie w miejscu gdzie jest logika (bo wtedy rozszerzanie systemu byłoby koszmarem).
Błąd zapewne ujawni się dopiero, gdy dane będą miały być użyte, wtedy nikt nie będzie wiedział jak ten błąd poprawić. Trzeba zejść z nim niżej (najprościej rzucając wyjątek).
Tak ja to rozumiem ;-)
W tym przypadku wyjątki nie będą wolniejsze (czas reakcji użytkownika - to dopiero jest koszmar).
Przy danych czytanych z pliku błędy można wykryć natychmiast (parser) - wtedy wyjątki są zbędne.
Ja zawsze używam wyjątków w sytuacji, gdy błąd trzeba obsługiwać 'gdzieś niżej'. Wydaje mi się, że do tego zostały stworzone.
0
@lmmilewski, ok i wyszło że się nie dogadaliśmy :) Ja miałem na myśli sytuację w których dane są błędnie wprowadzone np. String zamiast int'a. Ponad to reprezentuję podejście właściwe technologii EE gdzie za wszelką cenę programista powinien unikać wyjątków.
W aplikacjach o mniejszych wymaganiach rzeczywiście można niektóre rzeczy robić za pomocą wyjątków, ale musi być to podejście rozsądne. W książce "Java obsługa wyjątków i testowanie kodu " autor napisał coś w stylu:
Wyjątki wyrzucamy tam gdzie ich obsłużenie w powinno być w gestii użytkownika, resztę obsługujemy w miejscu wystąpienia.
Czyli można powiedzieć iż wyjątki powinny być wyrzucane tylko w miejscach styku naszego kodu i kodu klienta.
0
Dzięki za pouczająca dyskuję :)
Koziołek napisał(a)
@lmmilewski, ale wyjątek nie powinien służyć do obsługiwania sytuacji "prawdopodobnych" jakimi są np. błędnie wprowadzone dane. Takie problemy można, a wręcz należy rozwiązywać "polubownie" za pomocą np. komunikatów.
Co masz na myśli mówiąc "za pomocą komunikatów"?
0
Co do problemu błędnie wprowadzonych danych, to najlepiej wcześniej uprzedzić o wymaganym sposobie wprowadzania użytkownika, a jak ten nie posłucha (co prawdopodobnie się wydarzy) wyświetlić zwykłego dialoga z prośbą (żądaniem) o poprawienie danych i już.
Pozdrawiam
0
Mechanizm komunikatów. Najlepiej będzie jak podam przykład.
Użytkownik wprowadza dane → Dane trafiają do walidatora i są oznakowane jako błędne→ Tworzymy obiekt ErrorCommunicate (własne rozwiazanie) i kończymy działanie przez return null;
Następnie sprawdzamy czy obiekt ErrorCommunicate istnieje jak tak to analizujemy jego zawartość i wyświetlamy odpowiednie komunikaty o błędach.
Jak widać metoda jest stosunkowo prosta, ale wymaga zastosowania kilku sztuczek:
- Łańcuch walidacji. Coś podobnego do łańcucha filtrów w kontenerach web. Najlepiej jak w obiekcie ValidatorChain jest sobie nasz ErrorCommunicate
- Sprawdza się programowanie aspektowe do wstrzykiwania łańcucha walidacji na poczatku kontrolera.