Odpowiem z perspektywny Androida, ale wydaje mi się, że pasuje to do wszystkich frameworków. Rzeczy typu !!
albo requireNotNull()
powinny być używane tylko wtedy, kiedy framework za nas coś tworzy, przekazujemy potem tam jakiś parametr i w pewnym momencie chcemy go użyć, a jego brak oznaczałby błąd programu. Wtedy !!
wywala nam apkę i od razu pokazuje, gdzie mamy błąd, który musimy naprawić. Czasami może być to błąd frameworka, więc trzeba go zgłosić i tymczasowo korzystać z jakiegoś obejścia do czasu naprawy. W normalnym kodzie uważam, że nigdy nie powinno wystąpić !!
czy requireNotNull()
.
Wg mnie, wykorzystywanie null
w jakiejkolwiek logice powinno być uznawane za bad design.
Jeśli Ci się chce, zerknij sobie tu (lub znajdź sobie jakieś streszczenie tej prezentacji) - Tony Hoare - Null References: The Billion Dollar Mistake.
Nie zgadzam się z tym popularnym stwierdzeniem. null
sam w sobie nie jest problemem. Problemem jest niemożność rozpoznania nulla
na etapie kompilacji przez większość języków. Jeśli mamy brak wartości, to śmiało możemy używać nulli
, jeśli pozwala nam na to system typów i ma to sens z perspektywy modelowania.
Z drugiej strony nie jestem też pewny, że wybrali złe rozwiązanie. Po prostu widzę problem, ale nie wiem jak z tego wybrnąć dobrze i praktycznie. Ich rozwiązanie jakoś działa, ale poza obsługą nulli z javy i framorków nie stosuję T?
tylko Option<T>
. Co więcej nie mam przekonania, że dobrze robię...
(ale drażnią mnie trochę takie wyjątki w języku).
Ja mam w drugą stronę. Stosuję T?
a wydaje mi się, że bardziej eleganckie byłoby Option<T>
. Na Androidzie mogę sobie jeszcze to tłumaczyć tym, że khem, kehm wydajność
, ale to trochę oszukiwanie samego siebie. Option<T>
ma natomiast ogromną przewagę w przypadku korzystania z Reactive Streams. Specyfikacja tego po prostu zabrania i choćbym nie wiadomo jak tego chciał, to muszę to opakować w jakiś kontener. Z drugiej strony teraz pojawiło się Flow
w Kotlinie, więc pewnie będzie za jakiś czas de-facto standardem i problem zniknie.