Deklaracja, że metoda wyrzuca taki wyjątek jest tylko dla nas? Jak nie zadeklaruję to i tak mogę go przechwycić.
Czy coś się zmieniło?
0
0
Checked exception albo obsługujesz w try/catch albo rzucasz dalej. Deklarowanie rzucenia wyjątkiem w metodzie A służy do wymuszenia obsługi, bądź ponownego rzucenia wyjątkiem przez metodę B, która skorzysta z A. Trochę nie rozumiem pytania :D.
0
Jak pisałem od góry i coś wyrzucałem z metody, to IDE automatycznie mi poprawiało że trzeba zadeklarować.
Mało z Javą robiłem.
0
I dobrze podpowiadało, jeśli rzucasz checked exception "ręcznie" używając konstrukcji "throw new *Exception();" to... rzucasz wyjątek. Skoro rzucasz wyjątek to musi o tym wiedzieć deklaracja metody (bo go nie obsługujesz, tylko wyrzucasz dalej).
Analogicznie, niektóre API również deklarują wyjątki, jeśli w metodzie używasz takiego API, ale nie obsłużysz wyjątku, to wyjątek z tego API musisz przekazać dalej odpowiednio deklarując metodę (po prostu, jeśli czegoś nie obsługujesz, tylko rzucasz, to informacja o rzucaniu musi znaleźć się w deklaracji metody - dotyczy checked exceptions).
0
Jeżeli String jest empty, a w tym wypadku to nie może mieć miejsca, to nie ma sensu deklarować, po prostu wyrzucam, niech sypie błędami.
I dzięki za wyjaśnienie.
Źle to nazwałem - wydawało mi się że wymuszało a nie podpowiadało. Musiałem się poprawić :P
0
Może inaczej, w javie mamy tak zwane checked exceptions - jeśli ich nie obsłużysz bądź nie wyrzucisz dalej dostaniesz błąd kompilacji. Dlatego większość IDE podpowiada (a właściwie wymusza) te rozwiązania w takiej sytuacji. Są też unchecked exceptions (np. NullPointerException), o które IDE się nie upomni, bo nie ma po co - ich obsługa jest opcjonalna ;)
0
Warto dodać, że rozwój technologii idzie się w kierunku unchecked exceptions (są one wygodniejsze). Ewentualną informację o wyrzuceniu takiego wyjątku można dodać w celu lepszej czytelności dla przyszłego programisty patrzącego w ten kod, aczkolwiek informacja o tym, że jest możliwy NullPointer nie jest żadną informacją, bo on wszędzie może wystapić.
0
Ale tutaj ludzie są chętni do pomocy.
Chyba przez swoją pychę przymykam czasem oko na podstawy :D
Jeżeli się da uratować określając wartość domyślną to spoko, ale ja wole do tego moim zdaniem czytelniejszy operator trójargumentowy.
Jak coś zwracasz to można się pokusić o optional, albo gdy chcesz zamarkować argument że jest opcjonalny.
Chyba że źle optional zrozumiałem :P
0
Chyba źle zrozumiałeś. Optional to raczej coś stosowane jako wartość zwracana a nie jako argument. Żeby zasygnalizować ze dana metoda może nie zwrócic wyniku i trzeba to brać pod uwagę, szczególnie kiedy taka metoda nie rzuca wyjątku bo uważamy tą sytuacje za nie-wyjątkową.
Np. masz metodę która czegoś szuka w jakimś zbiorze danych i nie znalazła. Rzucenie wyjątku w takiej sytuacji może być dość dziwne, bo fakt że "nie znalazłeś" wcale nie jest wyjątkowy. Zwrócenie nulla jest ryzykowne bo ktoś może nie pomyśleć o tym że taka sytuacja wystąpi. Zwrócenie optionala od razu sygnalizuje że wartość może być "pusta" i trzeba coś z tym zrobić.
0
Aha
No to jego siłą jest sama nazwa.
Jako argument spoko, bo wtedy można często obejść się bez tworzenia kolejnego konstruktora lub metody.
A jak można zwrócić coś surowego, jakieś empty, to używanie optional moim zdaniem siało by tylko niepotrzebny zamęt.
Co do wyjątków to jeżeli można, to wolę dać metodę w stylu boolean będzieDobrze(), niż zaśmiecać komuś lub sobie kod : D
No ale jeżeli tak się piszę w Java to spoko, trzeba się dostosować.
0
@Wielki Lew ale czasem nie ma czegoś takiego jak "jakieś empty" bo każda mozliwa wartość jest poprawna.
Co do robienia własnej metody zamiast rzucenia wyjątku to znów bez sensu, bo robisz jeszcze gorszy bajzel. Bo teraz to user musi sie martwić żeby sprawdzać czy metoda sie poprawnie wykonała. Ciekawi mnie w ogóle jak to robisz, bez wykonania tych samych operacji dwa razy. Założmy że operacją jest wczytanie konfiguracji. Jak chcesz sprawdzić czy będzie dobrze bez wczytania? :D I rozumiem że wczytasz żeby sprawdzić czy będzie dobrze a potem żeby faktycznie wczytać? Dla kosztownych czasowo operacji to jest po prostu śmieszne. Nie mówiąc już o tym że to klasyczny błąd check-then-act bo przecież stan może się zmienic pomiędzy wykonaniem tych 2 metod...
A wracając do tego sprawdzania to teraz user się musi martwić jak obsłużyc ten błąd i w efekcie pewnie skończy sie właśnie tym że sam rzuci wyjątek żeby to ogarnąć gdzieś kilka poziomów wyżej w kodzie ;]
0
@Wielki Lew ale czasem nie ma czegoś takiego jak "jakieś empty" bo każda mozliwa wartość jest poprawna.
A no prawda, bywa i tak, i wtedy tak.
Wiesz, jeżeli to jest aż takie śmieszne, że aż mnie śmieszy, to wtedy tak nie robię : D
To wszystko zależy od sytuacji, łatwo jest tak gadać...
Bywa że staram się umieścić taką metodę, czasem dodatkowo też puszczam cichacze (wyjątki ninja, na które trzeba ustawiać pułapki) i w razie czego , to cofnąć zmiany, lub zwrócić przysłany obiekt.
Co do przykładu Twojego,
aż takim pajacem nie jestem - wtedy bym puścił obviousa : D
Przeważnie jak zostawiasz implementacje to zostawiasz problem.
W ogóle to nick mi się zmienił :P