![]() |
![]() |
![]()
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 ![]() |
@Crozin: to o czym piszesz to ułomność języka, który pozwala na pisanie bez jakiejkolwiek kontroli nad czymkolwiek, zrzucając wszystko na interpreter. Zwróćmy uwagę, że taka Java jest także językiem interpretowanym (przez JVM), ale jest prekompilowana do wersji przez JVM zrozumiałej. I wyjątki jako takie są w dużej mierze na etapie prekompilacji wyłapywane. Co nie zmienia faktu, że można kod napisać także w niej "po PHP-owemu", gdzie będzie cacy jeśli zrobimy jak chciał programista, ale jeden "byk" i wywali nam całą aplikację. Nie kłócę się też ze stwierdzeniem, że wyjątki to wymuszenie obsługi. To co po raz n-ty powtarzam to stosowanie tego mechanizmu jako remedium na wszystko co nieraz przeradza się w kuriozum. A co do "spostrzeżenia" to nie sugeruję, iż Ty uważasz za zamiennik to, ale że część programistów tak ten mechanizm stosuje i jest to moim zdaniem złe. Co do zmiany przepływu to wiesz dobrze jak działają wyjątki. One nie powodują zmiany przepływu, ale "wyskoczenie" z normalnego przepływu do najbliższego pasującego bloku catch. Nigdy jednak nie wiesz czy będzie to po 1, 5 czy 15 instrukcji wewnątrz bloku. Gdyby to do czegoś porównać, to chyba najprędzej do użycia goto, które także powoduje przejście do określonego miejsca w kodzie (etykiety), a które byłoby równoważne z blokiem catch.
@oboje: no właśnie... Świadomie ignorujemy. Obejmujemy blokiem try wszystkie operacje, gdyż wiemy jakiego typu wyjątek dostaniemy i tym samym usuwa się go z widoku. Jednocześnie jeśli w owym (owych) XML dostaniemy wyjątek tej samej klasy, ale tyczący czegoś innego, nawet się o tym nie dowiemy. W efekcie takie podejście ma sens identyczny ze stosowaniem @ przy operacjach w PHP. Można nawet nie wiedzieć, że coś działa nieprawidłowo, gdyż zamiast obsłużyć błąd, ignorujemy go dla naszej wygody lub "kompaktowości" kodu. Ja wiem, że to jest fajne i przyjemne rozwiązanie, ale podobnie jak @ powoduje problemy z debugiem aplikacji. W wersji batmana z owymi xml-ami tracę bowiem znacznie bardziej kontrolę nad tym co otrzymuję z serwerów, niż gdybym miał zrobić te ileś if-ów. Więcej pracy dla mnie, ale teżi kontrola nad całością większa i nie wyleję dziecka z kąpielą. Poza tym zwróćmy uwagę na jeden fakt... Zazwyczaj nie mamy jednej klasy wyjątku, ale całą ich hierarchię. Kod Crozina jest mocno uproszczony, gdyż przecież nie walimy kodu całej aplikacji w try i na końcu tylko bloczki catch uzupełniamy. Zazwyczaj bloki try-catch obejmują jedynie te fragmenty, które podejrzewamy o możliwe zaistnienie problemu określonego typu lub typów. |
|
|
![]() ![]() |
![]() |
Aktualny czas: 26.09.2025 - 13:40 |