Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

 
Reply to this topicStart new topic
> [PHP]Be sure that your exceptions honor layer abstraction.
porzeczki
post 30.12.2016, 14:49:58
Post #1





Grupa: Zarejestrowani
Postów: 144
Pomógł: 0
Dołączył: 15.09.2016
Skąd: Warszawa

Ostrzeżenie: (0%)
-----


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.

Ten post edytował porzeczki 30.12.2016, 15:05:52
Go to the top of the page
+Quote Post
Puszy
post 30.12.2016, 15:12:09
Post #2





Grupa: Zarejestrowani
Postów: 278
Pomógł: 42
Dołączył: 10.10.2011

Ostrzeżenie: (0%)
-----


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.

Ten post edytował Puszy 30.12.2016, 15:12:59
Go to the top of the page
+Quote Post
Crozin
post 30.12.2016, 18:20:46
Post #3





Grupa: Zarejestrowani
Postów: 6 476
Pomógł: 1306
Dołączył: 6.08.2006
Skąd: Kraków

Ostrzeżenie: (0%)
-----


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. ;-)

Ten post edytował Crozin 30.12.2016, 18:23:23
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 20.07.2019 - 21:37