Cześć. Używam JDBC do połączenia z bazą. Stworzyłem metodę, która jako argument przyjmuje polecenie sql, a zwraca w zależności ResultSet przy SELECT, lub null przy poleceniach, które nic zwracać nie mają. Null jest też zwracany w przypadku wyjątku złego polecenia sql, tak aby szybko korzystać z bazy za pomocą jednej metody, bez bawienia się w wyjątki na poziomie programowania tego, co faktycznie ma robić aplikacja. Moje pytanie brzmi: Czy zwracanie nulla w tych wypadkach i w ogóle ten sposób myślenia to dobra praktyka, czy nie koniecznie?
0
1
Mega słabym pomysłem jest informowanie o błędzie zwracając nulla i zwracając nulla jako brak wyniki... nawet nie że złym, ale bezsensownym.
Nie zwracasz nulla, zwracasz albo kolekcję która jest pusta jak nie ma wyników albo (lepszy pomysł) zwracasz Optional<Typ>
O błędzie z poleceniem informujesz wyjątkiem - po to one są.
EDIT
bez sensu, ja napisałem tylko swoją opinie, nie akceptuj odpowiedzi po 20min... poczekaj, ja chętnie posłucham co napiszę, bo ja wiem, @Shalom, @Koziołek, @Xix , @karolinaa or @katelx
0
dobra jako, że @niezdecydowany wywołał EKSPERCKIE SPEC GRONO DS. JAVA (jeszcze @complex niech się wypowie ). do rozważenia proponuję przypadek
w którym jest metoda ala Integer getJakasTamWartosc(); i gdy tej wartości nie ma to zwraca nula. Pomijając, że to taki dodatkowy stan w stosunku do int, to
żeby być uczciwym wobec Optionala - muszę wszystkie takie rzeczy przerabiać na niego? dużo tego ehh ;/ .
0
To ja jestem od zadawania pytań i ja baz danych jeszcze nie programowałem :) jeśli wy bardzo byście chcieli to mogę spytać ort! google :) Ale więcej z wami będę mógł gadać jak w końcu książkę o Java przeczytam (tak, chyba zostanę przy kochanej Javie po tym jak mnie z tremy po C++ Builder i C++ Vizual Studio wyzwoliła)
Zresztą mam braki w klasach z Java :)
1
Zwracanie wartości null przy błędzie nie należy do dobrych praktyk programistycznych. Lepiej zamiast tego zwrócić false, a gdy operacja się powiodła zwrócić true w przypadku funkcji boolean. W twoim przypadku ResultSet przy powodzeniu, pusta kolekcja i wyjątek przy niepowodzeniu.
3
@Lectre moim zdaniem powinieneś tą metodę rozbić na dwie i tyle. Zresztą tak jak i samo JDBC robi. Jedna która zwraca resultSety i powinna przyjmować np. selecty a druga która zwraca np. tylko czy sie coś powiodło albo ilość wierszy które zostały zmienione (insert, update). Robienie z tego jednej metody jest po prostu bez sensu.
0
Do końca nie rozumiem, skąd ta nienawiść do null'i. Wydaje mi się, że ich nadużywanie doprowadziło do sytuacji, w której zwracanie nulli jest złe na zasadzie "wszyscy wiedzą o tym". Tak, czytałem książki, Clean Code w szczególności. Zgadzam się z tym, że jeśli danych nie ma to należy zwracać puste kolekcje zamiast nulli.
ALE:
Mamy metodę zwracającą Integer. Jak rozróżnić, czy wartość jest niedostępna, czy też po prostu zerowa? Zakładając, że OBIE wartości mają swój sens biznesowy (przykładowo: kurs waluty na dzień bieżący - może być niedostępna i w teorii może być zerowy. Niedostępność kursu jednej waluty nie powinna blokować operacji).
3
imo nulle powinny byc zbanowane, ciezko mi uzasadnic ich istnienie w jezyku obiektowym. w twoim wypadku powinenes rozdzielic funkcjonalnosc na co najmniej dwie metody, nawet klasy i rzucac wyjatek a nie zwracac nulle