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?
Java 
- Rejestracja:ponad 12 lat
- Ostatnio:ponad 9 lat
- Lokalizacja:Bieszczady
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
edytowany 1x, ostatnio: niezdecydowany
Zobacz pozostały 1 komentarz
complex
Rzucanie wyjątku podczas niepowodzenia operacji to mega zły pomysł.
katelx
w jakiej elicie mi sie przyszlo znalezc, przyznam ze dopiero teraz czuje jak dobra decyzja byla rejestracja
panryz
uważaj na @karolinaa i @Xix oni potrafia omamić.
katelx
@panryz obawiam sie ze juz za pozno...
panryz
[*]
- Rejestracja:prawie 12 lat
- Ostatnio:prawie 5 lat
- Lokalizacja:Warszawa
- Postów:1683
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 ;/ .
dla mnie dzisiaj problemem jest niedziałająca formatka dla klienta na wczoraj - także też nic sofitikejted - nie wiem... może rozwiążmy jakiś problem z zaawansowanym algorytmem, znaczy wy rozwiążcie a ja się podepnę - bo nie umiem algorytmów, potem będziecie jeździć na konferencje, a ja z wami - będę siedział w starbaksie z białym maczkiem ...
Albo krzyżówkę, w końcu piątek jest
@niezdecydowany jeszcze wymysl haslo i statut dla tego koleczka
- Rejestracja:około 10 lat
- Ostatnio:prawie 9 lat
- Postów:231
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>wójka</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 :)
edytowany 2x, ostatnio: bogdans
- Rejestracja:prawie 10 lat
- Ostatnio:ponad 9 lat
- Postów:21
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.
edytowany 3x, ostatnio: complex
- Rejestracja:około 21 lat
- Ostatnio:prawie 3 lata
- Lokalizacja:Space: the final frontier
- Postów:26433
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).
Tutaj z pomocą może nam przyjść wzorzec projektowy o nazwie NullObject
Null jest w takiej sytuacji bez sensowny dlatego, że program jasno nie określa że ta metoda może nie zwrócić oczekiwanego wyniku i wymusza później defensywne sprawdzanie czy rezultat nie jest null'em. Jeżeli z góry zakładasz, że dana metoda może zwrócić NIC, to albo jawnie opakuj to w optionala (i nigdy nie zaskoczy Cię NPE dwie warstwy wyżej) albo tak jak napisał @panryz nie zwracaj typów prostych, tylko opakuj to w obiekt i zwróć NullObjecta powiązanego z tym obiektem.
Optional jest od Java 8 dopiero :)
W Guavie jest od dawna ;)
- Rejestracja:prawie 10 lat
- Ostatnio:5 miesięcy
- Lokalizacja:Hong Kong
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