Make: Typy błędów

0:00Cześć!

0:00W tej lekcji zakończymy już temat obsługi błędów, natomiast pokażę Ci jeszcze jedną

0:05bardzo istotną technikę, która uzupełni wykorzystanie error handler'ów.

0:09Mianowicie, jeżeli uruchomimy sobie nasz moduł, a następnie prześlemy na niego dane

0:13z pomocą webhook'a, to zobaczymy, że otrzymamy tutaj błąd w tym przypadku

0:18związany z faktem, że identyfikator rekordu jest niepoprawny.

0:21Natomiast poza tym nie mamy tutaj jasnej

0:23informacji mówiącej nam o tym, co dokładnie się stało.

0:27Ale już jeżeli dodamy sobie tutaj error handler,

0:29do którego w tym przypadku przypiszemy router, to zobaczymy, że

0:33jeżeli wykonamy ten scenariusz ponownie, no to okaże się, że uzyskamy tutaj dodatkową

0:38informację wskazującą na rodzaj błędu oraz wiadomość, która jest z nim związana.

0:44I o typach błędów musisz wiedzieć tyle, że

0:46są one uzależnione od tego, w jaki sposób zaprojektowane jest API.

0:50Jednak ogólna zasada mówi o tym, że

0:52konkretny rodzaj błędu powiązany jest z konkretnym rodzajem błędów.

0:57Natomiast ogólna zasada mówi o tym, że raczej typami możemy się kierować w

1:01kontekście tego, z jakim rodzajem błędu mamy do czynienia.

1:04I w tym przypadku jest to błąd wykonania

1:05informujący nas o tym, że jakiś rekord w ogóle nie istnieje.

1:10No i teraz możemy wykorzystać tą informacje o typie błędów do tego, aby

1:13utworzyć filtr, który będzie sprawdzać czy typ błędu, który wystąpi w naszym

1:18module, zgadza się z tym, co podamy tutaj.

1:21W efekcie możemy osiągnąć tutaj rezultat polegający na tym, że będziemy w różny

1:25sposób reagować na konkretne rodzaje błędów.

1:28Dla przykładu dla tego rodzaju błędów

1:29wysyłam wiadomość na Slack'u, ale już dla innego rodzaju błędu mógłbym ustawić inną

1:34reakcję, bądź też nawet całkowite zignorowanie tego błędu.

1:38Także najważniejsze jest tutaj to, aby

1:40było dla Ciebie jasne, że błędy mogą posiadać określony typ.

1:44Taki typ możesz odkryć w momencie, gdy wykonujesz jakąś akcję, a następnie do

1:48konkretnego modułu masz przyczepiony error handler.

1:51Wtedy w ramach wyniku tego modułu

1:53pojawiają się informacje o błędzie, które możesz wykorzystać.

1:57Zwróci uwagę, że nawet tutaj mamy

1:59konkretną informację na temat tego, w związku z jakim polem wystąpił błąd.

2:03Oznacza to, że z wykorzystaniem wyrażeń regularnych bądź funkcji.

2:07Wyszukując określony ciąg znaków w tekście

2:09bylibyśmy w stanie reagować na konkretne pola, które zostały źle uzupełnione i np.

2:14przydzielać im domyślną wartość lub w

2:16jakiś inny sposób reagować na to zdarzenie.

2:19Dodatkowo chciałbym zaznaczyć, że takie filtrowanie, które zastosowaliśmy w przypadku

2:23routera można równie dobrze zastosować w przypadku bezpośredniego error handler'a,

2:28czyli w tym przypadku zrobię tak, że obsługuje dany typ błędów.

2:32Natomiast w momencie, gdy będę miał do czynienia z innym rodzajem błędu, mój

2:36error handler tutaj nie zadziała, a sam scenariusz zostanie zatrzymany dokładnie

2:40tak, jakby żadnej obsługi błędów tutaj nie było.

2:43Dodatkowo przypominam Ci tutaj o opcji routera dotyczącej domyślnych ścieżek.

2:48Jeżeli w ramach filtra zaznaczysz ten o to

2:50checkbox, to ta konkretna ścieżka zostanie oznaczona strzałką bez ogonka, a

2:55co za tym idzie wykona się tylko wtedy, jeżeli filtry pozostałych ścieżek

2:59zadziałają i w rezultacie żadna z nich nie zostanie uruchomiona.

3:03Wtedy zostanie uruchomiony ten fallback, który w tym przypadku z programowania można

3:07porównać do bloku else, występujący w przypadku instrukcji warunkowych if.

3:11Także na koniec musisz pamiętać o tym,

3:14że możesz wykorzystać dodatkowe informacje, które są powiązane z

3:18konkretnymi błędami do tego, aby obsługiwać konkretne rodzaje błędów bądź

3:22też konkretne błędy, które przewidujesz, że mogą wystąpić.

3:26Poza tym chciałbym podkreślić, że

3:28informacje, które znajdują się tutaj, nie są wygenerowane automatycznie.

3:32One pochodzą bezpośrednio z API, a to oznacza tyle, że są w całości uzależnione

3:37od tego, w jaki sposób zaprojektuje je programista.

3:40To z kolei wiąże się z tym, że istnieje pewne prawdopodobieństwo, aczkolwiek nie

3:44jest to powszechna praktyka dotycząca tego, że rodzaje błędów mogą się

3:48zmienić z czasem i dodatkowo nikt Cię o tym nie poinformuje.

3:52Mi osobiście takie sytuacje się nie

3:54zdarzyły, natomiast musisz pamiętać, że coś takiego może mieć miejsce.

3:57Czasem będzie to działanie celowe, a w

3:59niektórych przypadkach może być wynikiem błędu.

4:02Oczywiście informuję Cię tylko o tym, natomiast nie zmienia to faktu, że takie

4:06sytuacje mogą mieć miejsce, ale bardzo rzadko.

4:09Chodzi o to, że w momencie gdy programiści projektują API, robią to również po to,

4:13aby sami z nich korzystać i z tego powodu nawet w ich interesie jest

4:18to, aby nie zmieniać typów błędów czy w ogóle struktury API.

4:22Także podsumowując, do obsługi błędów wykorzystuj również typy błędów oraz

4:26wszelkie dodatkowe informacje, które pojawiają się razem z tymi błędami.

4:30Do tego, aby projektować automatyzację w

4:32taki sposób, aby reagować odpowiednio na konkretne rodzaje błędów.

4:37Dodatkowo możesz wykorzystać również

4:39informacje o błędach do tego, aby przesyłać je dalej.

4:42I w tym przypadku chociażby mowa o wysłaniu wiadomości na Slack'u zawierającej

4:46konkretną informację o tym, jaki błąd tutaj wystąpił.

4:49Jeżeli chodzi o całościową obsługę błędów w Integromacie, to byłoby już na tyle.

4:54Zatem nie pozostaje mi nic innego jak podziękować Ci za uwagę.