Python: Obsługa błędów w aplikacjach internetowych

0:00Cześć witaj w kolejnej lekcji tym razem chciałbym opowiedzieć

0:04ci trochę obsłudze błędów naszej aplikacji webowej spróbujmy

0:09dodać nowy produkt i zamiast ceny wpisać

0:13jakiś łańcuch znaków dostaliśmy exception i

0:18my jako programiści powinniśmy być przyzwyczajeni do tego że

0:22nasz program dokładnie w detalach opisuje co

0:26spowodowało problem i jakiego typu błąd wystąpił jednak jeżeli

0:30robimy aplikację dla klienta lub nawet dla naszego kolegi to

0:34takie stwierdzenie value error tak naprawdę możemy powiedzieć nic dlatego

0:39też powinniśmy obsłużyć nasze wyjątki

0:43tak jak robiliśmy to w aplikacji konsolowej zobaczmy jak

0:47zrobić to w przypadku route'a add meal

0:52i co powinniśmy do niego dodać dostaliśmy

0:57informację że nie udało się przekonwertować naszego

1:01łańcucha znaków na typ float analizując nasz kod jesteśmy

1:06szybko w stanie stwierdzić gdzie następuje konwersja jest

1:10to linia 16 w tym momencie możemy

1:14dodać znany nam już znaną nam już klauzulę try except

1:19i

1:29sprawdzić czy nie wystąpił value error

1:35jeżeli

1:39tak się stało to warto podać szczegółową informację

1:44co stało się nie tak dostaliśmy

1:59konkretną informację dla użytkownika nie został przekierowany już

2:04na konkretną podstronę exeptionu dlatego

2:08też wszędzie gdzie możemy powinniśmy stosować właśnie tą konwencję obsługi

2:12błędów i informowania jak można naprawić

2:16zaistniałą sytuację zobacz teraz informacje unable to convert price

2:20jest konkretną daną którą może wykorzystać uzytkownik i

2:24wykorzystać ją w formularzu stosując prawidłowe dane i uzyskując

2:29potwierdzenie innym typem zwracania

2:34błędów są błędy samego serwera www zobaczmy

2:41na przykładzie naszej metody sum

2:45w jaki sposób możemy zwrócić i zasymulować

2:50jakiś problem z naszym serwerem użyjmy tutaj funkcji

2:55abort i podajmy w zależności od tego co się stało konkretny

3:01konkretną liczbę określającą błąd 403 będzie odpowiadało

3:05za problem z dostępem do konkretnego

3:09zasobu jest

3:13to domyślne zachowanie naszego serwera o

3:19nazwie forbidden że nie mamy dostępu jeżeli zmienilibyśmy tutaj liczbę na

3:23przykład na 404 to określiłoby to że nie mamy że

3:27dany zasób nie został znaleziony w naszym serwerze tak samo jest w przypadku liczby

3:31500 że wystąpił jakiś ogólny problem tak jak poprzednio

3:35ta informacja nie jest konkretna i jasna dla naszego klienta lub użytkownika

3:39dlatego też możemy użyć naszego kodu

3:43błędu wraz z customowym szablonem który

3:49zaraz pokażę ci jak stworzyć przejdźmy do naszego

3:54template'u i

3:58utwórzmy nowy plik html przygotowałem

4:03tutaj pomocniczy gif można to zrobić

4:07za pomocą tagu img

4:11w htmlu znanego nam już url for

4:15określanego jako static i nazwy pliku który podajemy

4:19w tej sekcji teraz wystarczy

4:23w naszym route'cie wyrenderować

4:30nasz template oraz

4:34przekazać dodatkową informację co

4:39tak naprawdę się stało okej

4:59podczas ponownego odświeżenia użytkownik

5:03jest przekierowywany na naszą stronę

5:07z błędem w tym przypadku tutaj nazwaliśmy go 404

5:11aby zachować spójność z

5:17serwerami www tworząc naszą aplikację również możemy

5:21przekazać ten numer błędu bezpośrednio

5:26do naszego route'a dzięki czemu będziemy wiedzieli że

5:34w naszej przeglądarce wystąpił problem z numerem 404

5:39gdybyśmy nie podali tej informacji to podczas odświeżenia

5:43nic by się nie stało są aplikacje które bazują na tego

5:48typu błędach dlatego też najlepszą praktyką jest od razu

5:52podawanie tej wartości do naszej przeglądarki w

5:57naszym wyrenderowany szablonie przekazaliśmy

6:02jedynie nazwę pliku jako 404 ale nasz route może

6:06również zwrócić kod błędu tak jak w poprzednio robiliśmy to

6:10z abortrem zobaczmy tutaj możemy podać 404 to

6:15nie zmieni całkowicie wyglądu naszej strony internetowej jednak kiedy przeniesiemy

6:20się do narzędzi deweloperskich to możemy określić

6:24że status naszej strony jest określony jako 404 część

6:29aplikacji i systemów monitorujących będzie bazować na tej informacji więc

6:33dobrą praktyką jest używanie tutaj konkretnych odpowiedzi i

6:38kodów błędów podczas zwracania naszego

6:42route'a zobaczmy tutaj 500 i mamy konkretną

6:47informację co się stało a użytkownik dalej znajduje

6:51się na naszej stronie i może przejść na inne podstrony z tego samego miejsca