Try vs Either - które wybrać?

Wiem, że Try obsługuje tylko wyjątki a w Either można też przedstawić błąd np. za pomocą enuma. Kiedy waszym zdaniem powinno się użyć Try a kiedy Either? Czy można powiedzieć, że jedno jest lepsze od drugiego?

https://stackoverflow.com/a/29779352

W skrócie Try<T> to praktycznie to samo co Either<Exception, T>.
Try jest bardziej kontekstowe, dajemy znać od razu konsumentowi, że operacja może się nie powieść i zakończyć wyjątkiem.

Try jest po prostu do opakowania rezultatu z jakiejś operacji na ogół I/O która może wyrzucić exceptiona, wtedy możesz też zmienić ten Try w Either lub Option.
Generalnie bym powiedział że Gry głównie służy do opakowania wywołań jakiś bibliotek I/O w większości przypadków ;)

scibi_92 napisał(a):

Try jest po prostu do opakowania rezultatu z jakiejś operacji na ogół I/O która może wyrzucić exceptiona

Czemu ograniczasz się tylko do sytuacji IO? W Javie prawie wszystko może rzucić wyjątkiem :(

Try nie jest funkcyjny. Jest funkcyjną łatą na wyjątki. Z drugiej strony warto być pragmatycznym. Jak twoimi błędami będą tylko wyjątki to proście używać Try niż Either. Chociaż niekoniecznie lepiej

@urke: @scibi_92: @KamilAdam: Rozumiem, ale lepiej przekazywać błąd jako np. enum w Eitherze czy jako wyjątek w Try? Załóżmy, że np. w czasie tworzenia konta pojawia się błąd typu "nieprawidłowa długość hasła". Jak najlepiej to obsłużyć?

Jak dla mnie to obsługiwać spodziewane błędy, mięć klasę bazową w stylu
Error, ErrorBase, whatever.
Tworzysz sobie konkretną implementację w stylu BusinessError, gdzie zwracasz kod błędu z opisem.
Dla mnie lepsze to niż jakieś enumy.
A rzucanie wyjątku, otrzymując OCZEKIWANY wadliwy ciąg to trochę dziwne.

Nieprawidłowa długość hasła to nie jest wyjątek, to że użytkownik nie potrafi ustawić poprawnego hasła to raczej standard. To nie jest sytuacja wyjątkowa. Walidacja nie powinna rzucać wyjatkami

Oczywiście że lepiej Either

W Javie prawie wszystko może rzucić wyjątkiem

Jeżeli piszesz swój kod to nie musisz robić sterowania logiki biznesowej wyjątkami . Wtedy zostają głównie operacje I/O i to one są zagrożeniem.

scibi_92 napisał(a):

Jeżeli piszesz swój kod to nie musisz robić sterowania logiki biznesowej wyjątkami . Wtedy zostają głównie operacje I/O są zagrożeniem.

W teorii tak. W praktyce trzeba niestety mnóstwo rzeczy owrapować bo nawet prasowanie stringa na inna potrafi rzucić exceptionem

Generalnie jeśli możesz wybierać to robisz Either. Wtedy błędy opisujesz przez jakieś sealed class lub enumy (z tym, że same enumy sie raczej nie nadają).
Try to taka łata, jak już ktoś Cię uraczył wyjątkiem i chcesz go jakoś z godnością przekazać.

Wyjątki są kuszącą opcją, ale raczej unikam ich, bo przy większęj złozoności, trudno się połapać, co się dzieje w kodzie i trudniej prześledzić jego wykonywanie. Z drugiej strony pytasz o Javę, a Java to Java; dużo zamieszania czasem może być z szablonami; już kilka razy stanęły mi na drodze w uformowaniu kodu tak jakbym chciał, bo coś było nie halo. No i Java słabo sobie radzi z domyślaniem się typów i trzeba je pisać daleko częściej niż bym sobie tego życzył. Z tego względu unikam Javy, a jeśli przyjdzie mi już programować w Javie, bardziej skłaniam się ku prostym rozwiązaniom i raczej rzucam wyjątkiem, uważając, żeby nie zagmatwać tego zbytnio. Jednak jest to mniejsze zło, a lepiej wybrać większe dobro i zmienić język programowania, choć wiem, nie zawsze się da.

@Baldr: dla mnie sytuacją wyjątkową jest np. jakiś SQLException, który leci bo zapis się z jakiegoś powodu rypie lub gdy z biznesowego punktu widzenia coś nie ma prawa się zadziać dajmy na to próba zwrotu środków pieniężnych gdy w systemie nie można odnaleźć takiej płatności

Baldr napisał(a):

Walidacja jak wspomniał @KamilAdam nie jest sytuacją wyjątkową. Co w takim razie według Was można zaliczyć do takiej sytuacji?

Sytuacja wyjątkowa to taka o której wystąpieniu chciałbym się szybko dowiedzieć i prawdopodobnie podjąć jakąś akcję. Czyli np. nieudane zapisy do bazy, 500 z zależności, złamanie kontraktu
Na wyjątki mógłbym mieć nawet zapiętą jakąś czujkę, żeby mogła mieć obudzić jeśli rzeczywiście coś jest nie tak.

Sytuacja wyjątkowa to taka o której wystąpieniu chciałbym się szybko dowiedzieć i prawdopodobnie podjąć jakąś akcję. Czyli np. nieudane zapisy do bazy, 500 z zależności, złamanie kontraktu

500 z zależności to żadna sytuacja wyjątkowa na ogół. Sytuacja wyjątkowa to coś czego raczej nie przewidujemy, np. wykrzaczenie się połączenia do bazy danych. 500 często nie jest sama w sobie sytuacją wyjątkową bo jak mamy komunikacja przez REST to wiadomo że coś może się zdarzyć nie tak, ja bym komunikacje z innymi serwisami obsłużył przez Either.
IMO dobrą praktyką jest wywalanie aplikacji kiedy coś mamy nie tak skonfiguwane np. kluczowa baza danych ma błędne parametry. Jak aplikacja jako całośc nie działa, to niech się po prostu wywali na starcie.

Wyjątek to sytuacja nie objęta kontraktem. Czyli zaszło coś czego nie spodziewaliśmy się, albo zdecydowaliśmy się, że nie obsługujemy.

To czego nie obejmuje kontrakt to już decyzja projektowa. Patrzymy czy klient (wywołujący funkcję) jakoś zawinił, lub może mieć jakiś sposób sensownego zareagowania na problem - jeśli tak, to raczej nie jest wyjątek. jeśli wołający funkcję nie ma wpływu lub nic nie może zrobić z problemem to raczej jest to wyjątek. Ale to jest decyzja zależna od kontekstu.
Przeważnie błąd zapisu do bazy danych to będzie wyjątek, bo ktoś wołając addUser("blablador") nie ma raczej na to wpływu, że coś się rypie z połączeniem, albo, że nie umiemy sklejać stringów, ale w pewnych sytuacjach możemy się umówić, że jest to jednak "rezultat", bo klient będzie wtedy np. wywoływał inną metodę np. zapis do kolejki.

Moim zdaniem wyjątki są dobre gdy jest jakiś problem infrastrukturalny np. brak połączenia z zewnętrzną usługą
albo problemy na styku aplikacji i bazy. Skutkuje to zwykle błędem wewnętrznym lub możemy złapać taki błąd/exception
i zrobić fail safe. Wyjątki są dobrą opcją również wtedy gdy np. aplikacja nie powinna się uruchomić ponieważ jest jakiś
błąd w konfiguracji np. spring-boot nie pozwoli na uruchomienie aplikacji dopóki wszystko w konfiguracji będzie ok
dlatego to jest dobre miejsce (tj. przed załadowaniem aplikacji) aby wczytywać różnego rodzaje zasoby, których aplikacja potrzebuje np. klucze/certyfikaty
i rzucać błędem jeżeli jest jakiś problem.

@VeloxDigitis: w aplikacjach bardzo biznesowych możesz kontrolować w pełni flow przez try lub either więc można spokojnie wyjątków nie rzucać, jedynie przekazywać.

Pisząc jakieś API które będzie używane przez różnych ludzi lepiej jednak trzymać niezależność od kontroli flow, wtedy wyjątki są spoko i można sygnalizować użytkownikom, że stało się coś niefajnego przez checked exception. Zwłaszcza gdy nasz kawałek kodu jest zależny od jakiegoś stanu zewnętrznego.

Gdy konstruujemy jakies api korzystajace z eitherow to wedlug mnie sytucja w ktorej pomimo eithera mozemy dostac wyjatkiem na twarz jest bardzo slaba.
W implementacji wszystkie "errory" logiki biznesowej powinny byc ubrane w Lefta. To ze cos nie przechodzi walidacji nie jest bledem krytycznym - w jakim celu wyjatek???.
Jedyne wyjatki jakie sa dopuszczalne (wedlug mnie) to te zwiazane z polaczeniem (baza danych/cos do czego uderzamy po sieci), jednak nawet w tym przypadku mozemy uzyc jednego z wielu mechanizmow recoverowania, dzieki czemu na wyjsciu otrzymamy dobrze zdefiniowanego lefta.