Używanie Exceptionów a typowanie Opcje

[athabus]

Ostatnio ciekawi mnie temat używania Exceptionów - muszę przyznać, że trochę słabo to czuję. Kiedyś Exception stosowałem do rzeczy, które po prostu mogły spowodować niedziałanie aplikacji - np. brak dostępu do pliku czy coś podobnego. Ostatnio jednak widzę, że coraz częściej w nowych bibliotekach Exceptiony stosuje się w inny sposób tj. do wymuszenia typowania metody bez zwracania NULL.

Np taka klasa:

[PHP] pobierz, plaintext 
<?php
 
class MySampleRepository
{
    public function getItemV1(int $id): SomeObject
    {
        //pobieramy item, który może nie istnieć (null)
        $item = $this->fetch($id);
 
        if (!$item) {
            throw new ItemNotFoundException('Item does not exist');
        }
 
        return $item;
    }
 
    public function getItemV2(int $id): ?SomeObject
    {
        //pobieramy item, który może nie istnieć (null)
        $item = $this->fetch($id);
 
        return $item;
    }
}
[PHP] pobierz, plaintext 

Pierwsza metoda (podejście o którym mówię) nigdy nie zwraca nulla, tylko obiekt lub rzuca wyjątek. Druga metoda (tradycyjna) zwraca obiekt lub null.

Które podejście stosujecie? Dlaczego.

Ja po rozmowie z kolegą zacząłem skłaniać się ku pierwszej wersji i brak możliwości zwrócenia oczekiwanego obiektu traktuję jako wyjątek.Podświadomie wydaje mi się to bardziej logiczne i wymusza trochę więcej dyscypliny.

[athabus]

Hej ale mamy XXI wiek i od takich rzeczy jest IDE (IMG:style_emoticons/default/wink.gif) Przcież w Javie też nikt nie klepie wyjątków z ręki a tam to chleb powszedni i obligatoryjnie musisz je obsłużyć.

W PHP storm metoda z nieobsłużonym wyjątkiem jest domyślnie podświetlona (+ edytor w docku domaga się dodania @throws jeśli wyjątek jest nieobsłużony).

Pisać też nic nie musisz - po prostu stajesz na takiej metodzie alt+enter i wybierasz surround with try/catch block i dostajesz kod z odpowiednim wyjątkiem/wyjątkami:

[PHP] pobierz, plaintext 
 
        try {
            $cacheItem->getValue();
        } catch (EmptyCacheItemException $e) {
        }
 
[PHP] pobierz, plaintext 

Taki zapis jak zaproponowałeś faktyczni byłby bez sensu bo po a - łapiesz WSZYSTKIE wyjątki co jest zaprzeczeniem idei tego mechanizmu, a po drugie obsługujesz je przez dziwaczną strukturę z if, która jest nieczytelna.

Takie porównanie kodu, aby było sprawiedliwie:

[PHP] pobierz, plaintext 
//wersja 1
        try {
            return $cacheItem->getValue();
        } catch (Cache\EmptyCacheItemException $e) {
            $item = $this->prepareItem();
            $this->cache->save($inlineImage);
            return $item;
        }
 
 
        //wersja 2
        if ($cacheItem->isHit()){
            return $cacheItem->getValue();
        }
 
        $item = $this->prepareItem();
        $this->cache->save($inlineImage);
        return $item;
[PHP] pobierz, plaintext 

Obie wersje są wg mnie czytelne i klarowne. Wersja 1 zmusza do świadomego obsłużenia wyjątku (IDE będzie o to krzyczeć) - w wersji 2 moim zdaniem łatwiej przeoczyć konieczność kontroli bo IDE już nie podpowie, żebyś sprawdził czy coś jest nullem. Przy fast fail musisz coś zrobić od razu z niewartościowym obiektem, a nulla możesz przekazać dalej w miejsce, gdzie ktoś już nie będzie zakładał, że może on być nullem a nie obiektem, którego oczekiwał.

Trochę wychodzi jakbym było orędownikiem wersji z exceptionami, a w sumie sam się zastanawiam, które podejście jest lepsze.

Ten post edytował athabus 1.01.2019, 19:57:16