![]() |
![]() |
![]()
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: Moderatorzy Postów: 4 362 Pomógł: 714 Dołączył: 12.02.2009 Skąd: Jak się położę tak leżę :D ![]() |
To może ja nieco dodam od siebie... Pracowałem trochę z C++, trochę z Javą, a obecnie głównie z PHP. Jako że od C zaczynałem to mam podejście mocno zbieżne z tym co pisze darko. Wyjątki tylko dla sytuacji wyjątkowych. A czym one są? Otóż zachodzą one w momencie gdy poprawnie napisana aplikacja natrafia na sytuację, która od niej zupełnie nie zależy. Przykład? Utrata połączenia z bazą danych już po jego ustanowieniu. Wyjątkiem nie jest natomiast sytuacja powszechna jak pomyłka i z dużą dozą przewidywalna. Zapewne jednak każdy dopasowuje kryterium "wyjątkowości" do siebie.
Dla mnie jeśli userowi napisałem, że pole pomieścić może 15 znaków do których należą same litery polskiego alfabetu (przykładowo imię) to wpisanie tam dłuższego lub z cyframi oznacza, że albo się pomylił, albo jest debilem (IMG:style_emoticons/default/smile.gif) Tak czy inaczej nie jest to sytuacja wyjątkowa i mogę zwyczajnie upomnieć usera oraz poprosić o poprawne dane raz jeszcze, nie dopuszczając do dalszej części aplikacji lub celowo ignorując błędne dane (jeśli mogę, gdy są nieobowiązkowe) i informując o fakcie, iż nie wezmą one udziału w dalszej fazie obróbki danych. Jeśli natomiast dane są prawidłowe, a mimo to nie mogę dalej pracować, to jest to już sytuacja wyjątkowa. Przykład? Plik istnieje, dane są ok, użytkownik ma prawo do pliku (wgrał go na serwer i jest powiązany z plikiem), ale... fizycznie są ustawione błędne prawa dostępu (ktoś skopał chmod kopiując pliki podczas przywracania backupu). Inny przykład? Użytkownik i aplikacja mają zezwolenie na wgrywanie określonego typu plików na serwer... ale ustawienia danego hostingu ten akurat format uznają za niebezpieczny. Czyli dochodzi do sytuacji, gdy wszelkie pozwolenia są ok, plik JEST na serwerze, ale ustawienia sprawiają, że odgórnie serwer nas i aplikację zlewa, nie dopuszczając do w pełni akceptowalnego typu danych. Sam miałem z takimi do czynienia. Najłatwiej więc to widać w sytuacji dostępu do zewnętrznego zasobu. Nie każda niemożność jest wyjątkowa. Jeśli zasobu od początku nie ma to trudno mówić by był to wyjątek. Po prostu nie ma go od samego początku i aplikacja zostanie zatrzymana już na starcie obróbki z powiadomieniem, że: "sorry batory, ale dalej się nie ruszę, nawet ciągnięta". Przykład? Obróbka pliku. Skoro oczekujemy tylko txt z określonym formatowaniem to tylko taki akceptujemy i każde odstępstwo nie jest wyjątkiem, ale błędnym typem danych i musimy zatrzymać proces obróbki do czasu poprawienia danych. Jeśli natomiast plik jest poprawny, ale w wyniku obróbki została wyczerpana pamięć dostępna to jest to coś niezależnego od samej aplikacji, mimo jej oraz danych poprawności. Nie podzielam opinii Orzeszkka co do tego, że wszystko co jest odstępstwem od zamierzonego działania jest jednocześnie sytuacją wyjątkową. Gdyby tak było, w kodzie nie byłoby ŻADNEGO if-else, a jedynie same try-catch. No bo skoro ciąg zdarzeniowy jest liniowy to nawet celowe rozgałęzienie kodu jest sytuacją wyjątkową, czyż nie? Jednak wiele z typowych sytuacji w procesie działania aplikacji, które kończą się błędami, wynika z ograniczonej liczby przewidywalnych łatwo pomyłek lub prób wpłynięcia na wynik poprzez preparowanie danych. Przytoczono przykład z datą... Skoro wyraźnie zaznaczam, że akceptuję tylko daty z podanego zakresu o określonym formacie to wszystko inne jest błędnymi danymi, ale w pełni wychwytywalnymi. Nie jest to nic specjalnego. Crozin... Zasugerowałeś, że try-catch powinno eliminować struktury kontrolne, gdzie ich wystąpienie jest wątpliwe i masz rację. Problemem jest jednak sytuacja, gdy programiści zaczynają wyjątki traktować jako alternatywną formę struktur kontrolnych. A takie coś sugeruje Orzeszekk. Jeśli domyślnie obsługujemy coś w jednakowy sposób, to każde odstępstwo = wyjątek. Innymi słowy dochodzimy do sytuacji, gdzie zamiast kilku if(-elseif)-else mamy dokładnie tyle samo bloków try-catch, których cel istnienia jest identyczny, ale robią to w, rzekomo, ładniejszy i łatwiejszy do ogarnięcia sposób. W ten sposób dochodzimy do takich aplikacji, gdzie cały kod to pierdylion try-catchy rzucających jeszcze więcej wyjątków do obsłużenia tak pozagnieżdżanych, że czytelność i konserwacja tegoż cierpią strasznie. A czemu? Bo programiście uwidziało się stworzyć strukturę wyjątków taką że hej i teraz musi jakoś to poodbierać, a że wyjątki dziedziczą jakoś po sobie, to tylko jeden, od którego dziedziczą inne złapie wszystkie naraz. Zaś przy bardziej szczegółowym trzeba łapać bardziej wyspecjalizowanymi (a więc odpowiedzialnymi za "gałęzie" wyjątków), czyli niejako wracamy do if-else, tylko że zbudowanego na wyjątkach. Sens tego żaden. |
|
|
![]() ![]() |
![]() |
Aktualny czas: 2.10.2025 - 16:26 |