Załóżmy, że mamy metodę:
ObjectTwo doSomething(ObjectOne o);
Metoda ta nie jest bezstanowa. Czasami może prawidłowo zwrócić instancję ObjectTwo, a czasami nie i do takiej sytuacji nie chcemy dopuścić. Stan klasy jest niedostępny z zewnątrz. Oba flow funkcji są 'oczekiwane', tzn. całkiem normalne, że dla danego parametru i stanu będziemy chcieli powiadomić użytkownika naszego API, że nie można wykonać akcji. Wielowątkowość odstawmy na bok. Pomińmy, proszę, sprawę frameworków. Wiadomo, że fajnie łapie się Runtime w interceptory, ale załóżmy, że jest to aplikacja konsolowa.
Pytanie, w jaki sposób zaprojektować API, żeby dla klienta było bezpieczne i przyjemne?
- Dodać w API metodę sprawdzającą czy wszystko gra i można wywołać metodę doSomething
boolean isAbleToDoSomething(ObjectOne o);
? Każde wywołanie będzie musiało poprzedzać sprawdzenie czy takie wywołanie ma sens, co już samo w sobie jest słabe.
-
Rzucać RuntimeException.
-
Rzucać CheckedException.
-
Zmienić sygnaturę na Optionala?
-
Wasze propozycje.