Wpis z mikrobloga

Najlepiej ich nie rzucać


@krasnoludkolo: z "nie rzucać" się niezbyt zgadzam, za to zdecydowanie uważam że nie należy ich łapać jeżeli sytuacja absolutnie tego nie wymaga.

Oczywiście rzucanie ma sens tylko wtedy kiedy mamy zamiar umieścić w nim jakąś użyteczną informację. throw new RuntimeException(String.format("Invalid line %d, expected 5 columns but got %d", lineNumber, line.length)) jest spoko. Za throw new Exception("Process failed"); wypadałoby autora zwolnić zanim zdąży napisać kończący linię średnik ;)
@vasco_da_gama: imo należy wyjątki zostawić na faktyczne wyjątki (zerwnie połączenia z bazą danych, błąd sieciowy itp) natomiast na wszystkie inne przypadki zostawiać normalną obsługę z kodu.

np. typowy przykład. Wyciągasz Usera z bazy. 90% wyjątków dostajesz albo Usera albo UserNotFoundException, który jest automagicznie (albo i czasem nie) łapany/mapowany dalej.
ja natomiast staram się zwracać Either z albo wartością, albo jakiś enum z błędem (piszesz w scali to domyślam się, że wiesz
@vasco_da_gama: to już podchodzi o opieranie logiki kodu o wyjątki. To bardzo słabe ale się przyznam, w 2010-11 zrobiło się popularne jain-slee dla telco, a akurat pisałem dla jednego z telekomów i tam logicznie się nie dało inaczej tego rozwiązać, inne podejścia były zbyt drogie, a o to w tym framework chodziło

jain-slee umarło
to już podchodzi o opieranie logiki kodu o wyjątki.


@d_u_p_a: imho dopóki ich nie łapiesz to nie. Więc to zależy - np w podanym przeze mnie przykładzie parsowania pliku CSV - jeżeli plik pochodzi od użytkownika to nie jest to wyjątek (to w końcu normalne że użytkownik czasami wyśle nam śmieci). Jeżeli plik został pobrany z bazy danych przez jakiegoś robota - coś poszło wybitnie nie tak, więc rzucamy wyjątek zamiast