![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 21 Pomógł: 1 Dołączył: 6.04.2009 Ostrzeżenie: (0%) ![]() ![]() |
Witam. Chciałem się dowiedzieć, kiedy NALEŻY stosować wyjątki w OOP? Chodzi mi o konkretne przykłady i jakieś dobre wytłumaczenie.
Wyjątki jak sama nazwa wskazuje, ale np . Kod $a=5; $b=0; if($a<$5){ ... } Też mogli byśmy użyć wyjątków? i czy powinno się? bless |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%) ![]() ![]() |
@darko: A masz jakiś pomysł jak zareagować na sytuację nieprzewidzianą? No bo jeżeli wstawisz instrukcję warunkową i wyrzucisz wyjątek to jest to jak najbardziej "normalna", przewidziana sytuacja, co nie?
Cytat Oprócz tego, co napisałeś czy nie jest tak, że wyjątki stosuje się wtedy, jeśli można przywrócić normalny stan aplikacji sprzed wystąpienia problemu (tj. po obsłużeniu błędu)? Rzadko kiedy taka sytuacja ma miejsce. Z reguły wystąpienie błędu kończy się wymogiem jakiejś reakcji ze strony użytkownika i ewentualnym wznowieniu, a raczej ponownym uruchomieniu, danej akcji.Cytat Czy funkcja w php czytająca plik rzuci wyjątek czy zwróci false? Znowu wracamy do kwestii indywidualnej każdego z nas - tj. czy używać wyjątków do sterowania logiką aplikacji czy tylko w sytuacjach faktycznie wyjątkowych, gdzie zostawiamy wolne pole do obsługi napotkanego problemu? Powinna bezsprzecznie wyrzucić wyjątek, co więcej powinien istnieć wymóg jawnej obsługi lub oddelegowania takiego wyjątku. Zwrócenie false jest paskudną i wyjątkowo podatną na błędy praktyką. Cały sens istnienia wyjątków to właśnie wyeliminowanie takiego zjawiska (o czym pisałem post wcześniej).PS. Nie ma czegoś takiego jak "dane pochodzące od użytkownika traktowane w inny sposób". Dane od użytkownika to nic innego jak zewnętrzny zasób, którego format czy poprawność nigdy nie jest pewna. Ten post edytował Crozin 31.10.2011, 16:20:22 |
|
|
![]()
Post
#3
|
|
Grupa: Zarejestrowani Postów: 2 885 Pomógł: 463 Dołączył: 3.10.2009 Skąd: Wrocław Ostrzeżenie: (0%) ![]() ![]() |
@darko: A masz jakiś pomysł jak zareagować na sytuację nieprzewidzianą? No bo jeżeli wstawisz instrukcję warunkową i wyrzucisz wyjątek to jest to jak najbardziej "normalna", przewidziana sytuacja, co nie? Dokładnie, dlatego najczęściej obejmuję blokiem try {} catch {} kod, który nie jest mojego autorstwa i nie mogę przewidzieć, jak się zachowa, jak dostanie niepoprawne dane. Sprawdzam wtedy czy i jakie wyjątki wyrzuca i staram się obsłużyć wszelkie możliwe przypadki. Rzadko kiedy taka sytuacja ma miejsce. Z reguły wystąpienie błędu kończy się wymogiem jakiejś reakcji ze strony użytkownika i ewentualnym wznowieniu, a raczej ponownym uruchomieniu, danej akcji. Ok, ale jeśli nie ma możliwości wykonania żadnej akcji i z góry to wiadomo, to wyjątek nie ma racji bytu w takim miejscu. Bo niby po co? Chyba, że dalsze działanie aplikacji może wiele napsuć. To już jest wyjątkowa sytuacja (IMG:style_emoticons/default/smile.gif) W przeciwnym razie wystarczyłby zwykły komunikat będący efektem sprawdzenia (if - else). Natomiast inaczej sprawa wygląda, jeśli możemy "olać" pewien niedobór danych (czy niespełnienie kryterium), ale nie musimy i tutaj należy zostawić pole dla programisty, który będzie korzystał z naszego kodu - dać mu możliwość zadecydowania, co w takiej sytuacji zrobić? Może dla niego, w jego użyciu naszego kodu nie będzie to niezbędne? Staram się uchwycić faktyczne sytuacje, kiedy wyjątki są niezbędne. Powinna bezsprzecznie wyrzucić wyjątek, co więcej powinien istnieć wymóg jawnej obsługi lub oddelegowania takiego wyjątku. Zwrócenie false jest paskudną i wyjątkowo podatną na błędy praktyką. Cały sens istnienia wyjątków to właśnie wyeliminowanie takiego zjawiska (o czym pisałem post wcześniej). A jednak różnie bywa: file zwraca false, fopen również przy czym "If the open fails, an error of level E_WARNING is generated. You may use @ to suppress this warning." (- czy to jest eleganckie rozwiązanie? Nie.), file_get_contents - j.w., SplFileInfo::openFile generuje RuntimeException - ok. PS. Nie ma czegoś takiego jak "dane pochodzące od użytkownika traktowane w inny sposób". Dane od użytkownika to nic innego jak zewnętrzny zasób, którego format czy poprawność nigdy nie jest pewna. A czy nie jest tak, że niezależnie od tego, co przyjdzie od użytkownika, programista spodziewa się określonych danych w pewnym formacie o danej maksymalnej długości i typie? Czy to nie jest sytuacja przewidywalna? Według mnie jest i nie jest w żaden sposób wyjątkowa. Zamiast upychać wszędzie rozmaite podhierarchie wyjątków można pewne rzeczy wymusić, albo - po przeprowadzeniu walidacji - zwrócić komunikat(y) błędu/błędów i czekać na poprawienie danych przez użytkownika. Czy walidatory wyrzucają wyjątki? Nie. Dalej nie mam przekonania czy powinniśmy stosować wyjątki dla sytuacji przewidywalnych, dla których znamy z góry wymagane kryteria (przecież często sami je narzucamy) i oczekujemy określonego rezultatu czy też lepiej używać instrukcji warunkowych i wymuszać pewien stan rzeczy? PS. kiedyś przyszło mi pracować z kodem, gdzie w każdym niepewnym miejscu autor po prostu zatrzymywał działanie skryptu poprzez die('coś tam'). Niestety nie mieliśmy zbyt dużo czasu, żeby zapoznać się z kodem i wyszedł z tego mega zonk. Z kolei z drugiej strony - zdarzyło mi się korzystać z biblioteki do obróbki grafiki (jakaś darmowa, nazwy nie pamiętam) - tu z kolei autor dla każdej bzdury rzucał wyjątkami na prawo i lewo, np. rozmiar obrazka był za duży lub z mały - throw new Exception('Obrazek ma niepoprawny rozmiar'); - i tyle. Ani słowa na temat czy rozmiar jest za mały czy za duży? Ogólnie chodzi o to, żeby korzystać z wyjątków z głową, stosując przy tym wcześniej dobrze przemyślaną hierarchię. Nie wystarczy po prostu korzystać z wyjątków. Powód każdego rzucanego wyjątku powinien być bardzo szybko "identyfikowalny", a komunikat jasny i czytelny. Pozostawiam indywidualnym preferencjom decyzję, kiedy i w jakich sytuacjach wykorzystywać wyjątki. Ten post edytował darko 31.10.2011, 18:29:15 |
|
|
![]() ![]() |
![]() |
Aktualny czas: 4.10.2025 - 03:38 |