co jest optymalniejsze/lepszą praktyka?
Optional<> x = Optional.ofNullable(JakisObiekt);
if (x.isPresent()){
...
}
lub po prostu
if (JakisObiekt != null) {
...
}
co jest optymalniejsze/lepszą praktyka?
Optional<> x = Optional.ofNullable(JakisObiekt);
if (x.isPresent()){
...
}
lub po prostu
if (JakisObiekt != null) {
...
}
Nie wiem czy java już to ma, ale w tym przypadku lepiej użyć peek(). Jeżeli Optional będzie posiadał wartość, to wtedy wykona funkcję.
Optional bo wtedy pamiętasz że może być pusty. Jak dla mnie jeśli metoda zwraca nie optionala to znaczy że obiekt będzie nie nullem, jesli zwraca optionala to może wystapić null... ale najlepiej zwrócić Optiona
Tak jak pisze @scibi92 - najlepiej przyzwyczaić się do Option z VAVRa.
Ale i Optional
jest nadal BEZPIECZNIEJSZY od nulla. null
nie powinien się w zwykłym kodzie pojawiać, chyba, żę gdzieś w jakiejś krytycznej sekcji kodu walczysz o cykle, bo np. zajmujesz się symulacjami fizycznymi.
Sens Option/Optional widać dopiero jak przestaniesz używać operacji:
~~isPresent~~~i get()
One się w normalnym kodzie nie powinny pojawiać! Świadczą o tym, że ktoś kopiuje bedna obsługe nulla na Optionale.
Używaj tych metod głównie:
map
, flatMap
przede wszystkim. Ewentualnie peek
, forEach
i orElse
.
Wtedy dopiero widać sens Optionala (np. nie pisze się tyle ifów co przy nullach).
EDIT:
Czyli w szczególności - ten cały fragment poniżej to nonsens. Tak samo słaby jak ten z nullem.
Optional<> x = Optional.ofNullable(JakisObiekt);
if (x.isPresent()){
...
}
if(x.isPresent())
bez sensu. Zależnie co robisz:->
użyj map.ifPresent ( x -> ... )
orElse
:Przykład
x = JakisObiekt.map( x -> x+2).orElse(7)
dzieki za rozjasnienie, generalnie zawsze stosowalem Optionala np przy wyciaganiu z repo spring data findById(); , ale wczoraj w pracy dostalem ‚zj**ke’ robisc jakiegos fixa, bo uzylem of.Nullable i niepotrzebnie wydluzylem kod etc. etc.
tego chyba (?) zbytnio nie da sie obsluzyc optionalem wczesniej bo wyglado to mniej wiecej tak:
jest formatka z uzupelnieniem danymi
jest pole typ i grupa tego typu
jezeli wybierzemy z selecta typ, to automatycznie w labelce group ajax da przyporzadkowana wartosc dla grupy
no ale jesli nie wybierzeby typu -> to nie mamy grupy, typ jest normalnie walidowany na formatce, ale grupa nie bo jest dodawana ajaxem. co powodowalo ze jesli nie wybierzemy grupy to lecial null pointer w kodzie na walidacji tej grupy przypisanej z ajaxa (co jest wedlug mnie kompletnie bez sensu bo skoro jest przypisywana automatycznie, to po co tak na prawde ja walidowac, skoro jest ona z gory zalozona)
no generalnie kod ten to jeden wielki misz masz.
napisalem ten temat bo faktycznie jak mi mentor powiedzial ze to co zrovilem to jest przerost formy nad trescia to chcialem byc pewny ze tak jest;)@jarekr000000:
dzieki za rozjasnienie, generalnie zawsze stosowalem Optionala np przy wyciaganiu z repo spring data findById(); , ale wczoraj w pracy dostalem ‚zj**ke’ robisc jakiegos fixa, bo uzylem of.Nullable i niepotrzebnie wydluzylem kod etc. etc.
tego chyba (?) zbytnio nie da sie obsluzyc optionalem wczesniej bo wyglado to mniej wiecej tak:
jest formatka z uzupelnieniem danymi
jest pole typ i grupa tego typu
jezeli wybierzemy z selecta typ, to automatycznie w labelce group ajax da przyporzadkowana wartosc dla grupy
no ale jesli nie wybierzeby typu -> to nie mamy grupy, typ jest normalnie walidowany na formatce, ale grupa nie bo jest dodawana ajaxem. co powodowalo ze jesli nie wybierzemy grupy to lecial null pointer w kodzie na walidacji tej grupy przypisanej z ajaxa (co jest wedlug mnie kompletnie bez sensu bo skoro jest przypisywana automatycznie, to po co tak na prawde ja walidowac, skoro jest ona z gory zalozona i nie sprawdzamy bledu wprowadzenia uzytkownika)
no generalnie kod ten to jeden wielki misz masz.
napisalem ten temat bo faktycznie jak mi mentor powiedzial ze to co zrovilem to jest przerost formy nad trescia to chcialem byc pewny ze tak jest;)
dzieki za rozjasnienie, generalnie zawsze stosowalem Optionala np przy wyciaganiu z repo spring data findById(); , ale wczoraj w pracy dostalem ‚zj**ke’ robisc jakiegos fixa, bo uzylem of.Nullable i niepotrzebnie wydluzylem kod etc. etc.
tego chyba (?) zbytnio nie da sie obsluzyc optionalem wczesniej bo wyglado to mniej wiecej tak:
jest formatka z uzupelnieniem danymi
jest pole typ i grupa tego typu
jezeli wybierzemy z selecta typ, to automatycznie w labelce group ajax da przyporzadkowana wartosc dla grupy
no ale jesli nie wybierzeby typu -> to nie mamy grupy, typ jest normalnie walidowany na formatce, ale grupa nie bo jest dodawana ajaxem. co powodowalo ze jesli nie wybierzemy grupy to lecial null pointer w kodzie na walidacji tej grupy przypisanej z ajaxa (co jest wedlug mnie kompletnie bez sensu bo skoro jest przypisywana automatycznie, to po co tak na prawde ja walidowac, skoro jest ona z gory zalozona)
no generalnie kod ten to jeden wielki misz masz.
napisalem ten temat bo faktycznie jak mi mentor powiedzial ze to co zrovilem to jest przerost formy nad trescia to chcialem byc pewny ze tak jest;)
Promować używanie nulli, masakra =/
Kiedyś słyszałem mądrą myśl, że maven powinien mieć plugin'a, który formatuje dysk, jak znajdzie return null
Tak z ciekawości, co sądzicie o takim kawałku kodu (obsługa null values):
public void dummy() {
List<String> remotes =
Arrays.asList("http://nowhere/a", "http://nowhere/b", "http://nowhere/c");
List<byte[]> data =
remotes
.stream()
.map(
s -> {
try {
return externalDownloadmethod(s);
} catch (IOException e) {
return null;
}
})
.filter(Objects::nonNull)
.collect(Collectors.toList());
}
private byte[] externalDownloadmethod(String url) throws IOException {
// .....
}
Exceptionon handling w lambdach kupowato wygląda (ciekawe gdzie nie wygląda).
Lepiej, użyć VAVRowego Try
w takim przypadku.
List<byte[]> data =
remotes
.stream()
.map(s -> Try.of ( ()-> externalDownloadmethod(s)))
.filter(Try::isSuccess)
.filter(Try::get)
.collect(Collectors.toList());
}