Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [PHP]Be sure that your exceptions honor layer abstraction.
Forum PHP.pl > Forum > Przedszkole
porzeczki
http://www.brandonsavage.net/exceptional-p...-to-exceptions/

Cytat
Be sure that your exceptions honor layer abstraction.
One of the more complicated things about handling exceptions is that you want to honor layer abstraction when throwing and catching exceptions.

For example, let’s say that PDO raises an exception due to a unique key constraint in the database. Unhandled, it will bubble up to the top. If the PDO exception was caused by something in your Controller, allowing the PDO exception to bubble up would be a violation of layer abstraction.

A better choice would be to catch the PDO exception and wrap it in a Controller exception. For example:


  1. <?php
  2.  
  3. try {
  4. // some PDO action here
  5. }
  6. catch(PDOException $pdoE)
  7. {
  8. throw new ControllerException('There was an error: ' . $pdoE->getMessage() );
  9. }

Cytat
When the exception bubbles up, the PDO exception will have been handled, but the message will be included in a ControllerException. This is an acceptable way to handle exceptions that honors the principle of layer abstraction.


Nie rozumiem po co owijanie wyjątków i wyrzucanie kolejnych. W czym to ma pomóc? I tak na końcu widzę na ekranie (Symfony profiler) komunikat o błędzie i linię z błędem. Co mi daje inna nazwa klasy exception?

Bo, wcześniej se zanotowałem z innych internetów, przypadki ponownego wyrzucania wyjątków (owijania):
  • -gdy w mojej bibliotece używam 3rd party library
    -..i nie chcę by klient mojej biblioteki widział exceptions z 3rdPL.
  • - gdy na kolejnych poziomach warstw abstrakcji dodaję nowe fakty.
    -..pomocne w ostatecznych naprawieniu błędu
    -..pomocne w lepszym zrozumieniu błedu.
  • -jeśli nie jesteś w stanie naprawić exception na niższym poziomie
    -..to re-throw i bąbelkuj w górę.

No ale przykład z bloga mi nie pasuje do niczego z powyższych.
Puszy
Cytat(porzeczki @ 30.12.2016, 14:49:58 ) *
Nie rozumiem po co owijanie wyjątków i wyrzucanie kolejnych. W czym to ma pomóc?


Jeżeli nie rozumiesz tego to nie będziesz nigdy w pełni korzystał z obsługi błędów, nie możesz ograniczać się do jednego try catch. "Wielopoziomowe" try catch usprawnia pracę, np. łapiesz wyjątek, w catchu wykonujesz jakąś akcję (ustawiesz pole Status w encji na "ERROR") i sypiesz wyjątkiem wyżej, funkcja wyżej wykonuje kolejną akcję jak np logowanie błędu etc. Dzięki takim wielopoziomowym wyrzucaniem wyjątków ograniczasz się do try catch zamiast pisać tysiące IFów.
Crozin
Podany fragment kodu z tego bloga to idealny przykład jak kompletnie spartaczyć sobie obsługę i debuggowanie błędów. Tego typu kod to dosłownie same problemy.

Przede wszystkim jeżeli nie masz żadnej możliwości zareagowania na wyjątek, ani możliwości zignorowania go pod żadnym pozorem nie łap go - wyrządzasz sobie w ten sposób jedynie krzywdę. Zauważ, że w tym kodzie:
1. Tracimy informację o miejscu wystąpienia błędu. W linii #8 nie doszło tak na prawdę do żadnego błędu (miało to miejsce w czymś co tutaj kryje się pod komentarzem z linii #4). Tracimy BackTrace'a.
2. Tracimy informację o tym co spowodowało wyjątek - dostaniemy tylko nic nie mówiący ControllerException z komunikatem w stylu "There was an error: Connection TimedOut". Jeżeli jeszcze zapisałby oryginalny wyjątek czy w praktyce zapewne ich całą hierarchię...
3. W kodzie kontrolera, który generalnie powinien kompletnie nie interesować się źródłem danych (baza danych, PDO) musimy tworzyć tego typu zależność.

I jeszcze odnośnie Twoich wcześniejszych notatek dot. łapania i ponownego rzucania wyjątków.
1. Tak, możesz wyłapać wyjątek zew. biblioteki i opakować go we własny, tylko pamiętaj by przekazać go w parametrze, jako innerException.
2. Jeśli nie jesteś wstanie nic z nim zrobić to nawet nie kombinuj z łapaniem go i ponownym wyrzucaniem bez żadnej pobocznej akcji jak chociażby zalogowanie go - sam to zrobi.

PS. Nie mogę pozwolić sobie teraz na lekturę tego wpisu, ale powyższy fragment spowodował u mnie zapalenie się takiej ostrzegawczej lampki w głowie. ;-)
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2024 Invision Power Services, Inc.