php - obsługa błędów

pytanie zadane 26 listopada 2018 w PHP przez niezalogowany

dzień dobry,

Zastanawia mnie w jaki sensowny i dobry sposób obsługiwać błędy?

np:

    function deleteVideo($videoID){
        if(self::videoAvailable($newVideoID)){
// wiadomosc
            return false;
        }
        $result = DBManager::makeQuery("DELETE FROM videos WHERE videos.videoID = '$videoID'");
        return $result;
    }

Taki kod, chciałbym aby funkcja w momencie kiedy warunke "if(self::videoAvailable($newVideoID)){" jest spełniony zwracała fałsz, jednocześnie chciałbym móc obsłużyć jakiś komunikat aby wyświetlać np na stronie, jakie macie patenty na takie rzeczy? Nie chodzi mi tutaj o proste echo, bo jednak chciałbym móc potem za pomocą html / css wiadomosc umiejscowić jakoś na stronie. Natomiast return z treścią wiadomości to też słaby pomysł bo chciałbym mieć fałsz.

powinienem zrobić całkowicie osobną funkcje do tego?

1 odpowiedź

odpowiedź 26 listopada 2018 przez Arkadiusz Waluk Ekspert (287,950 p.)

Do obsługi błędów w PHP są wyjątki. Nie wiem jak masz napisaną aplikację, ale jeśli to kod strukturalny to dużo trzeba będzie zmienić - na pewno wygodniej byłoby, gdybyś pisał obiektowo.

komentarz 26 listopada 2018 przez niezalogowany
edycja 26 listopada 2018

Aplikacje staram się pisać obiektowo ale chyba nie do konca jeszcze rozumiem intencje osoby, która zaprojektowała ten sposób tworzenia aplikacji więc tworze sobie klasy, a w nich funkcje i jakos to idzie. Chce stworzyc pierwsza działająca aplikacje póki co.

W ten sposób:

    function deleteVideo($videoID){
        if(!self::videoAvailable($videoID)) {
            throw new Exception("Nie można usunąć tego filmu ponieważ nie istnieje.");
            return false;
        }

        $result = DBManager::makeQuery("DELETE FROM videos WHERE videos.videoID = '$videoID'");
        return $result;
    }

Natomiast try / catch zrobiłem przy samym wywołaniu tej funkcji.

try{
    $films = $vm->deleteVideo('ID_FILMU');
}catch(Exception $e){
    $films = $e->getMessage();
}

Zastanawia mnie tez fakt czy nie powinienem błędów wyłapywać już na początku czyli w definicji funkcji, a nie dopiero przy jej wywołaniu?

komentarz 26 listopada 2018 przez Tomek Sochacki Ekspert (227,510 p.)

W przypadku kodu pisanego w sposób synchroniczny to z tymi wyjątkami też tak z rozwagą trzeba pracować.... przy małej apce rzędu parudziesięciu requestów na sekundę to luzik, ale jak masz apkę rzędu tysięcy requestów w sekundzie to okazuje się, że obsługa wyjątków może być dość czasochłonna i zasobożerna, przynajmniej w Javie, nie wiem jak to dokładnie odnosi się do PHP choć nie spotkałem za bardzo żadnej faktycznie dużej apki w PHP.

Natomiast na pewno nie wolno olewać błędów, bo to pierwszy krok do problemów i fajnie, że autor posta do dostrzega. Ja bym jednak polecał iść raczej w stronę czegoś bardziej async lub reactiv co daje sporo fajnych ficzerów w kompleksowym spojrzeniu na obsługę requesta, błędów, odpowiedzi itp.

komentarz 26 listopada 2018 przez Arkadiusz Waluk Ekspert (287,950 p.)

Mniej więcej. Za rzuceniem wyjątku już nie musisz robić nic, ten return się nie wykona, wyjątek przerywa wykonywanie kodu. Warto też wiedzieć, że można robić własne klasy wyjątków, w razie potrzeby wrzucić do nich własną logikę. Nie jestem też pewien czy polskie komunikaty błędów są dobrym pomysłem - raczej stawiałbym na angielskie i ewentualnie to co ma trafić do użytkownika tłumaczył, ale to już może być kwestia dyskusji i podejścia bo np. tam gdzie jest ścisła walidacja i wyjątki takie nie są ścisłymi błędami systemu polskie tłumaczenie może być pożądane.

Łapanie go tak jak tu robisz jest ok i będzie działać, ale w praktyce wyjątki mogą dać dużo więcej. Na przykład rzucasz wyjątek gdzieś ze środka kodu, następnie masz jedno miejsce w aplikacji w której łapiesz wszystkie wyjątki, tam logujesz błędy, generujesz jakiś ładny widok dla użytkownika itp. Robi się taka łatwa, przyjemna i kompleksowa obsługa błędów.

@Tomek Sochacki jak mam być szczery to nie pracowałem (jeszcze - mam taką nadzieję) nigdy przy aplikacji obsługującej tysiące requestów na sekundę. Wszędzie gdzie do tej pory pracowałem w PHP używane były wyjątki i nikt nie robił z tym problemów, nie zastanawiał się nawet czy możemy ich użyć czy nie. Z całą pewnością jeszcze brakuje mi wielu doświadczeń, w tym takich. Myślę jednak że wyjątki to przydatna wiedza, więc na poziomie autora pytania (bez urazy tutaj rzecz jasna) jeśli je pozna i będzie używał to moim zdaniem tylko wyjdzie to na korzyść. A dalej może poznać inne tematy. Rzucisz jakieś konkretne przykłady co masz na myśli mówiąc o rzeczach "bardziej async"?

komentarz 27 listopada 2018 przez Tomek Sochacki Ekspert (227,510 p.)

Myślę jednak że wyjątki to przydatna wiedza

Co do tego nie ma wątpliwości, powiedziałbym nawet, że dobrego programistę można poznać własnie po tym czy i jak obsługuje błędy, bo wiele osób początkujących w ogóle o tym zapomina...

Wszędzie gdzie do tej pory pracowałem w PHP używane były wyjątki i nikt nie robił z tym problemów, nie zastanawiał się nawet czy możemy ich użyć czy nie

wszystko do czasu... wiele osób, mówię teraz o back-endzie, nie zastanawia się też np. nad analizą puli wątków (mówię na przykładzie Javy), zużyciem procesora przez poszczególne mikrousługi, zużyciem ramu itp. itd. Ale przy większych aplikacjach, gdzie masz paredziesiąt tysięcy requestów w sekundzie to takie kwestie są już bardzo istotne...

Rzucisz jakieś konkretne przykłady co masz na myśli mówiąc o rzeczach "bardziej async"?

Jasne, co prawda może nie z podwórka PHP bo tego języka nie lubię i lubić nie będę :) ale np. w Javie mamy teraz Spring 5 który pięknie wspiera reactiv style, do tego jak podepniesz dobie Server Sent Events w API i na froncie z np. rxjs to masz świetne rozwiązanie reaktywne, dające mega duże możliwości. Powiedziałbym, że to taki level wyżej niż typowe,książkowe operacje asynchroniczne znane z kursów na poziomie podstawowym. Wszelkie błędy, timeouty itp. ogrywasz wtedy również w sposób reaktywny co pozwala Ci bardzo przyjemnie dla programisty i usera obsługiwać wiele różnych scenariuszy.

To jest myślę właśnie kierunek webu... co więcej, jak wspomniałem wspiera to praktycznie by default Spring 5, na froncie rxjs jest już standardem w Angular, SSE wspierają praktycznie wszystkie nowsze przeglądarki, jedynie w zasadzie potrzebny jest polyfill dla IE11 i Edge ale to nie jest wielkie wyzwanie.

Co prawda są pewne głosy niechęci ze względu na implementację w Springu WebFluxa innego od RXJava ale to są w zasadzie moim zdaniem pierdoły, a po za tym rxjavę da się pożenić ze Springiem 5 więc to jak zwykle bywa są głosy ZA i PRZECIW.

Ja osobiście bardzo lubię programowanie reaktywne, w średniej wielkości i dużych apkach jest to moim zdaniem świetne rozwiązanie, które pozwala naprawdę bardzo fajnie pracować, szczególnie w świecie mikrousług, co jest dziś chyba coraz częściej standardem (szczerze to nie znam w zasadzie żadnej nieco większej apki opartej na monolicie, gdzie bym nie rozmawiał to wszyscy idą w mikroserwisy i właśnie coraz więcej osób idzie w reactive style).

komentarz 27 listopada 2018 przez Arkadiusz Waluk Ekspert (287,950 p.)

wszystko do czasu... wiele osób, mówię teraz o back-endzie, nie zastanawia się też np. nad analizą puli wątków

Dlatego w swoim komentarzu napisałem "jeszcze - mam nadzieję" :) Z pewnością to byłoby ciekawe doświadczenie, jak każde nowe, więc liczę na to, że kiedyś będzie mi dane spróbować się to w zagłębić.

Dzięki za obszerne wyjaśnienie. Javy dokładnie nie znam, ale coś trochę temat kojarzę i brzmi to bardzo fajnie. Chętnie bym się zagłębił nawet już, tyle że czas średnio pozwala, z resztą nie wiem czy w PHP ma to aż taki potencjał - albo nie słyszałem albo nie ma. A głosy "za" i "przeciw" są oczywiście za wszystkim, wszystko ma zalety i wady, więc to jasne.

komentarz 27 listopada 2018 przez Tomek Sochacki Ekspert (227,510 p.)

tyle że czas średnio pozwala

jak ja to doskonale znam... :)

z resztą nie wiem czy w PHP ma to aż taki potencjał

obiło mi się jakiś czas temu coś o Rx Observable do PHP ale nie wiem czy są to projekty faktycznie tak rozwijane jak np. w Javie. Wydaje mi się, że PHP chyba bardziej jest wykorzystywany w mniejszych apkach, pomijając szereg "typowych" stron, gdzie po prostu jest do niego wiele CMS itp.

Ciekaw jestem jeszcze jak wygląda porównanie np. Java i Spring vs C# i .Net, moze kiedyś znajdzie się czas na jakieś małe prywatne PoC ale na razie, jak zresztą zauważyłeś, chyba każdy ma tego czasu za mało :)

komentarz 27 listopada 2018 przez Arkadiusz Waluk Ekspert (287,950 p.)

Chyba większość to zna. Znaczy powiem tak, jakbym się bardzo postarał to bym czas znalazł, ale to byłoby latanie: komputer w pracy < - > komputer w domu bez odsapnięcia, a myślę że nie na tym życie polega :)

Odnośnie PHP to nie wiem czy to są koniecznie "mniejsze apki", zależy też co to dla kogo jest "mniejsza". Zgodziłbym się jednak że taka Java wydaje się większą machiną i znacznie bardziej zaawansowaną, a więc daje też wspomniane ciekawe możliwości, PHP pod tym względem jest taki jakby uproszczony. Co nie znaczy że PHP mi się nie podoba czy że nie da się w nim nic napisać, żeby nie było - komentarze i dyskusje o tym jak PHP umiera i do niczego się nie nadaje uważam za śmieszne.

komentarz 27 listopada 2018 przez Tomek Sochacki Ekspert (227,510 p.)

komentarze i dyskusje o tym jak PHP umiera i do niczego się nie nadaje uważam za śmieszne.

100% się zgadzam, PHP jest, był i będzie, wiele stron na tym stoi i fajnie, bo ma on niski próg wejścia i pozwala szybko coś postawić, chociaż patrząc na jakość kodu wielu nowicjuszy to można by dyskutować nad zaletą tego niskiego progu :)

Nikt też nie przepisze apki wykonanej na zlecenie np. na Javę jeśli klient za to nie zapłaci... a zapłaci, jeśli dostanie faktyczny zysk z czegoś takiego i tu kółeczko się zamyka :)

Ja powiem Ci, że bardzo niechętnie siadam do PHP jak muszę coś pogrzebać w starszym kodzie, ale to głównie przez brak jakieś jednolitej spójności chociażby w nazewnictwie funkcji na przestrzeni różnych wersji itp. No i Javie (i Kotlinowi) bliżej do TypeScripta :) a jak wiadomo nie od dziś, JavaScript (i TS) to jedyne słuszne języki :P (PHP, Java, C i cały ten inny syf nie umywa się do JS :D )

komentarz 27 listopada 2018 przez Arkadiusz Waluk Ekspert (287,950 p.)

Racja, jakości kodu dobrej nie wymusza. Ale z drugiej strony gdybyśmy chcieli pozbyć się wszystkiego, czego człowiek źle używa, to trochę opustoszałby ten świat ;) Jasne, kasa jest ważna, ale też nie ma co przesadzać - jak ktoś pisze system na przeciętnego bloga i ma kasę, a programista chciałby to postawić w Javie to spoko, może stawiać, ale myślę że PHP również świetnie dałby sobie radę i jeśli klient ma zapłacić za napisanie w Javie więcej "bo tak" to chyba nie tędy droga - dobierajmy technologię do tego, co trzeba zrobić.

No to ja Ci powiem że praktycznie codziennie siadam do PHP, da się z tym żyć! :D Co więcej wolę go bardziej niż taki JavaScript, choć w pracy robię trochę za fullstacka i jakiś JS czy Vue też mi się przewija co jest i fajne i nie - fajne bo zawsze coś nowego poznam, niefajne bo wiadomo jak to jest w pracy, trzeba coś zrobić i gdy nie masz o tym dobrego pojęcia i wykładasz się na prostych rzeczach to czas leci... W każdym razie niech sobie każdy pisze w czym lubi, co się do czego umywa nie będę określał bo jeszcze ktoś to serio potraktuje i nam się dostanie ;D