Jak @fasadin napisał, żeby iść na forum to na forum.
Czy jest jakikolwiek przypadek kiedy warto zwracać nulla zamiast Optionala/Option? Chodzi o sytuację gdy funkcja poprzez swoją "naturę" może takiego nulla wypluć.
Wyłączając przypadki:
Spodziewam się ciekawej dyskusji. Też chciałem zapytać, bo używanie nulli jest tu na forum strasznie flamowane. A taki np. Kotlin nie uznał za stosowne wykluczyć nulla z zasięgu programisty i daje wygodne narzędzia do współżycia z nullami, np. operator elvis. Ja na razie oddaję głos za nullem, jako naturalnym sposobem oznaczania braku prawidłowego wyniku działania funkcji.
Z nullami mogę używać dokumentacji javadoc albo adnotacji @NotNull, @Nullable. Nie ma wtedy zgadywania.
Ja używam Optionala z dwóch powodów - bezpośrednio pokazuję, że funkcja może zwrócić nulla (co według mnie jest bardziej czytelne niż adnotacja), no i używanie go według mnie ładniej wygląda niż
if ( x == null ){
// coś tam
}
Chociaż drabinka lambd też potrafi czasami zamotać.
jarekczek napisał(a):
Z nullami mogę używać dokumentacji javadoc albo adnotacji @NotNull, @Nullable. Nie ma wtedy zgadywania.
Nawet biarac najbardziej optymistyczny przypadek, ze jest javadoc i faktycznie jest tam napisane ze moze zwrocic nulla, bedziesz czytal javadoc i reverse-engineer'owal kod kazdej nienapisanej przez ciebie metody aby sprawdzic czy tam nie bedzie czasem nulla? Albo wszystkie zewnetrzne metody pakowal w if'a?
Masz type system, wykorzystaj go jak najlepiej bo to jedno z niewielu narzedzi, ktore na dzien dzisiejszy moze Ci pomoc.
@jarekr000000
jak mnie sie to porownanie podoba, zrodlo:
W dobie kiedy Java zaczyna wygladac jak basic czas sie chyba zastanowić nad starymi nawykami.
@Nullable itp .wydawały mi się kiedyś dobrym pomysłem, ale w praniu jakoś nie działa. Najwygodniej jest przyjąć, że nie sprawdzam nulli doputy coś nie jest jasno określone jako @Nullable
(@NotNull to w ogóle nonsens). Tyle, że w praktyce potem nigdy nie mam pewności czy IDE było dobrze skonfigurowane, sonar rzeczywiście prawidłowo podpięty, itp. Za często się to rozjeżdża, żeby spokojnie zaufać, a mi się nie chce regularnie sprawdzać.
W moich projektach zwracanie null z jakiejkolwiek funkji uznaję za sabotaż. Jak ktoś nie lubi Optionala to niech chociaż wali exceptionem wtedy.
Technicznie to nie miałem dużych problemów z przekonywaniem ludzi do optionali, ale raz musiałem pokazać taką prezentację:
https://www.slideshare.net/JarekRatajski/fighting-null-with-memes
Tam gdzies pod koniec jest pokazana przewaga Optionala nad drabinką ifów.
Kotlin robi to całkiem elegancko, bo w zasadzie ma w język wbudowanego optionala, jak chcemy mieć coś nullable to trzeba jasno zadeklarować i bedzie to sprawdzane przez kompilator.
Inaczej nie ma nulli. (Chyba, że wywołujemy stary kod z javy, wtedy null może się przedrzeć).
IMO minusem Optionala/Option jest to, że niepotrzebnie wydłuża nazwę typu, tzn.
Pojo pojo = new Pojo();
// vs
Optional<Pojo> pojo2 = Optional.of(new Pojo());
To jest bardziej słabość Javy, niż samego Optionala ale jest to irytujące.
Druga, cudza opinia pod którą się podpisuję - Optional to fajne narzędzie do ogarnięcia nulli, ale w rękach niewprawnego programisty może urządzić dużo większe szkody i może być dużo cięższe do debugowania,
Ja uważam że nie ma sensu robić takich metod które zwracją null zamiast Optionali. Oczywiście jak mam Optionala i programuje imperatywnie to zdarza sie coś ala:
if (optional.isPresent()) {
}
Ale chodzi o to że widać że metoda może coś zwrócić albo nie :)
Czy jest jakikolwiek przypadek kiedy warto zwracać nulla zamiast Optionala/Option?
Tak. Kiedy robimy gdzieś finalne przypisanie wartości do pola i to pole jest nullable. Ale to raczej dość oczywiste, no bo coś trzeba w takiej sytuacji zrobić ;) A tak poza tym to nie warto.
Nie wiem czy dobrze zrozumiałem temat, ale jeśli tak to osobiście korzystam z takiego rozwiązania:
Metoda ZAWSZE zwraca jeden typ danych. Jeśli jest prawdopodobne że coś może w niej pójść nie tak a rzucenie exceptiona nie jest możliwe to metoda zawsze zwraca boolean'a. Wtedy z poziomu wywołania metody sprawdzam:
if(obj.method()) {
var = obj.getResult();
}
Dzięki takiemu rozwiązaniu nie trzeba sprawdzać czy to co zwrócił obiekt jest spodziewanym wynikiem, lub co gorsza używać jakiegoś switcha na rezultat wywołania metody.
@NickOver
edit: to co opisałeś to właśnie Optional/Either.