[PHP] Błędy w klasach |
[PHP] Błędy w klasach |
27.06.2008, 20:35:32
Post
#1
|
|
Grupa: Zarejestrowani Postów: 654 Pomógł: 17 Dołączył: 19.03.2006 Skąd: z kosmosu ;) Ostrzeżenie: (0%) |
Witam, jak lepiej obsługiwać błędy z poziomu klasy?
trigger_error()" title="Zobacz w manualu PHP" target="_manual Czy wyjątki?
Do tej pory kożystałem z wyjątków, ale coś mnie podkusiło aby się zapytać co do tego trigger_error()" title="Zobacz w manualu PHP" target="_manual @edit Zastanawiam się nad tym dlaczego iż wyjątki nie są aż takie wygodne... Gdy ktoś ma error_reporting wyłączony to obsługuje klasę jak zwykłe funkcje z jądra PHP, a przy obsłudze wyjątków trzeba try {} i catch{} za każdym razem stosować przy tworzeniu obiektów. Dziękuję, Babcia@Stefa Ten post edytował Babcia@Stefa 27.06.2008, 20:38:05 -------------------- Środowisko testowe (desktop) - Gedit, lighttpd, sftp, rsync, xfce4-terminal, chromium, firefox4 | System: Gentoo ~x86
O'Neill - serwer WWW @ lighttpd, links, nano, rsyncd, sftpd | System: Debian |
|
|
27.06.2008, 20:39:23
Post
#2
|
|
Grupa: Zarejestrowani Postów: 1 873 Pomógł: 152 Dołączył: 9.04.2006 Skąd: Berlin Ostrzeżenie: (0%) |
Ja bym obstał przy wyjątkach. Ale trochę inaczej. Często można spotkać ten sposób w wielu frameworkach.
Wtedy, jeśli masz zamiar inaczej wyświetlać wiadomość
i w kodzie
EDIT: Nie lubie edycji postów. Co do try {} i catch{}. Ja w sowim kodzie wystarczy, że użyje ich raz. Przy uruchomieniu kontrolera, który uruchamia sobie resztę, ale wyjątek i tak zostanie złapany. Bo się w nim mieści. PS. Przy __autoload() wyjątki siadają niestety Ten post edytował bim2 27.06.2008, 20:41:03 -------------------- |
|
|
27.06.2008, 22:31:54
Post
#3
|
|
Grupa: Zarejestrowani Postów: 535 Pomógł: 27 Dołączył: 3.05.2005 Ostrzeżenie: (20%) |
I po kłopocie |
|
|
28.06.2008, 08:36:08
Post
#4
|
|
Grupa: Zarejestrowani Postów: 1 873 Pomógł: 152 Dołączył: 9.04.2006 Skąd: Berlin Ostrzeżenie: (0%) |
autoload" title="Zobacz w manualu PHP" target="_manual
Cytat Informacja: Exceptions thrown in __autoload function cannot be caught in the catch block and results in a fatal error. ;-/ Ten post edytował bim2 28.06.2008, 08:36:33 -------------------- |
|
|
28.06.2008, 08:56:12
Post
#5
|
|
Grupa: Zarejestrowani Postów: 535 Pomógł: 27 Dołączył: 3.05.2005 Ostrzeżenie: (20%) |
Niestety
|
|
|
28.06.2008, 09:01:32
Post
#6
|
|
Grupa: Zarejestrowani Postów: 654 Pomógł: 17 Dołączył: 19.03.2006 Skąd: z kosmosu ;) Ostrzeżenie: (0%) |
Doszedłem do takiego rozwiązania. -------------------- Środowisko testowe (desktop) - Gedit, lighttpd, sftp, rsync, xfce4-terminal, chromium, firefox4 | System: Gentoo ~x86
O'Neill - serwer WWW @ lighttpd, links, nano, rsyncd, sftpd | System: Debian |
|
|
28.06.2008, 09:07:39
Post
#7
|
|
Grupa: Zarejestrowani Postów: 1 873 Pomógł: 152 Dołączył: 9.04.2006 Skąd: Berlin Ostrzeżenie: (0%) |
Widzę, że chcesz to zrobić elastycznie, ale w przypadku błędów tak się nie da. Zobaczysz to później. Uchwyć się jednego rozwiązania (polecam wyjątki) i nim obsługuj błędy. Przecież i tak od ciebie zalezy jak błędy wyświetlisz, zapiszesz i co z nimi zrobisz. Można nawet robić na własnej klasie obsługi błędów, tylko po co, jeśli mamy udostępnione porządne narzędzie?
Ja wyjątki wyrzucam tradycyjnie, a później
I display() zapisuje mi loga z linia, nazwa pliku oraz z post i get itd. oraz wyrzuca stosowny błąd na ekranie. Bardzo fajny jest tracker, dzięki któremu widzę przebieg ładowania programu. EDIT: To błędów nie wrzucaj nigdy ozdobników tylko suche błędy. I jak najwiecej informacji, co pozwala znaleźć błąd. Ten post edytował bim2 28.06.2008, 09:11:16 -------------------- |
|
|
30.06.2008, 09:25:24
Post
#8
|
|
Grupa: Zarejestrowani Postów: 793 Pomógł: 32 Dołączył: 23.11.2006 Skąd: Warszawa Ostrzeżenie: (0%) |
@ Babcia@Stefa
Wyjątki są o wiele wygodniejsze, mimo że musisz umieszczać kod w bloku try{} to umożliwia Ci jednak rozpoznanie co to za błąd i naprawę. Ale nie można tego robić, że masz jedną klasę wyjątków Exception, tylko każdy typ błędu powinien mieć swoją własną, czasem to będzie tylko zmiana nazwy aby móc zastosować pewną konstrukcję:
No i to co napisałe bim2, możemy rozszerzać własne wyjątki, które dadzą nam takie metody które są nam potrzebne. -------------------- Algorytmy w PHP, czy ktoś o tym słyszał?
Dlaczego tak mało kobiet programuje? ponieważ nie zajmują się głupotami. |
|
|
3.07.2008, 21:33:41
Post
#9
|
|
Grupa: Zarejestrowani Postów: 102 Pomógł: 12 Dołączył: 27.01.2007 Skąd: north Poziom: 158 Tytuł: Miszcz Ostrzeżenie: (0%) |
@Sedziwoj: nie trzeba tworzyć każdorazowo klasy do typu błędu (dobrze jest to robić, ale nie jest to niezbędne). W deklaracji klasy exception widzimy:
I prototyp konstruktora wygląda następująco:
Czyli zamiast tworzyć X klas, możemy po prostu wrzucać do parametru $code dowolną stałą / liczbę która może nam zidentyfikować błąd. A przewaga wyjątków nad trigger_error() jest znaczna - za ich pomocą możesz opanować sytuację i nawet nie wypluwać info o błędzie tylko zaradzić jemu. -------------------- Blog | plugin system by carbolymer
Residence: #php.pl @ IRCNet "Pralki powstały po to, aby kobiety też mogły programować" |
|
|
3.07.2008, 21:42:24
Post
#10
|
|
Grupa: Zarejestrowani Postów: 793 Pomógł: 32 Dołączył: 23.11.2006 Skąd: Warszawa Ostrzeżenie: (0%) |
@Sedziwoj: nie trzeba tworzyć każdorazowo klasy do typu błędu (dobrze jest to robić, ale nie jest to niezbędne). Czyli zamiast tworzyć X klas, możemy po prostu wrzucać do parametru $code dowolną stałą / liczbę która może nam zidentyfikować błąd. Wiesz, nierozróżnienie wyjątku jest przydatne, jeśli jego obsługa jest ta sama, czy prawie ta sama. Ale jak jest błąd połączenia z baza danych i nieprawidłowe parametry, to jednak powinny to być inne wyjątki, bo co innego się robi. Jak już masz błąd połączenia, to możesz kodem opisać co jest przyczyną. Taki ja mam pogląd. -------------------- Algorytmy w PHP, czy ktoś o tym słyszał?
Dlaczego tak mało kobiet programuje? ponieważ nie zajmują się głupotami. |
|
|
3.07.2008, 21:50:46
Post
#11
|
|
Grupa: Zarejestrowani Postów: 102 Pomógł: 12 Dołączył: 27.01.2007 Skąd: north Poziom: 158 Tytuł: Miszcz Ostrzeżenie: (0%) |
@Sedziwoj: no ja się zgadzam z tobą, sam nawet stosuję te rozróżnienie na klasy, chciałem tylko przedstawić sprawę w innym świetle.
-------------------- Blog | plugin system by carbolymer
Residence: #php.pl @ IRCNet "Pralki powstały po to, aby kobiety też mogły programować" |
|
|
4.07.2008, 04:03:02
Post
#12
|
|
Grupa: Zarejestrowani Postów: 206 Pomógł: 18 Dołączył: 6.03.2006 Skąd: Szczecin Ostrzeżenie: (0%) |
oczywiscie polecam rozwiazanie polegajace na wyjatkach. niewatpliwie jest ona bardziej elastyczne (ze wzgledu na mozliwosc chociazby zagniezdzenia blokow try{} catch{} wiec mozesz umiescic swoj starszy kod wewnatrz takiego bloku i nie bedzie problemu) a jednoczescie umozwiliajace dosc dobra kontrole nad przebiegiem wydarzen (jak widac na poszczegolnych juz przytoczonych przykladach mozna dosc szczegolowo kontrolowac zdarzenia zaleznie od tego, jaki blad wystapi). najwazniejsza przewaga wyjatkow nad trigger_error() jest to, ze jest to kontrukcja jezykowa (jak takze widac).
ze swojej strony moge dodac klase wyjatkow, ktora w nieznaczny sposob modyfikuje zachowanie klasy bazowej, a umozliwia proste rozroznienie wyjatkow tej samej rodziny po konkretnych przypadkach (kodach bledow):
http://opentibia.svn.sourceforge.net/viewv...S_ErrorCode.php oczywiscie roznica jest nieznaczna, ale z poziomu kodu o wiele wygodniej jest obslugiwac kody bledow, niz ich wiadomosci. -------------------- Wrzasq.pl
Tworzenie stron i aplikacji internetowych. Chillout Development - tworzenie stron i aplikacji internetowych. |
|
|
7.07.2008, 14:05:19
Post
#13
|
|
Grupa: Zarejestrowani Postów: 1 873 Pomógł: 152 Dołączył: 9.04.2006 Skąd: Berlin Ostrzeżenie: (0%) |
Jeśli masz gdzieś rozpiskę tych kodów, co jaki znaczy. Mi prościej jest przekazać cały błąd i informację z nim związane, np "Can't load file [ścieżka do pliku]". Oczywiście gdy user nie ma praw wyświetla mu się identyfikator błędu oraz ja dostaje powiadomienie na emaila. Szybciej się debuguje aplikację niż szukać jaki kod co oznaczał.
-------------------- |
|
|
7.07.2008, 14:16:20
Post
#14
|
|
Grupa: Przyjaciele php.pl Postów: 5 724 Pomógł: 259 Dołączył: 13.04.2004 Skąd: N/A Ostrzeżenie: (0%) |
Bledy phpowe sa do D....., nic ci nie daja, wywala napis na ekran [ktorego w 99% nie chcesz tam widziec] a program leci sobie dalej, co z tego ze nie polaczyles sie z baza, skrypcik proboje na tym nieistniejacym polaczeniu wywolywac zapytania [a wyjatek ucieknie ci poziom wyzej, a dokladniej do pierwszego catch'a i nie pozwoli ci na takie bezsensowne akcje w skrypcie].
Mozesz przeciez uzyc IF'y, wszedzie, prawie co linijke, az szlak cie trafi. No i tracisz jedna z wartosci zwracanych przez funkcje, ktora musisz przeznaczyc na pokazanie ze nastapil blad. Ja nie korzystam z kodow bledow w wyjatkach [moze sie kiedys przydadza, ale na razie nie byly mi potrzebne], kazdy rodzaj bledu ma swoja klase np. RecordNotFound, FileNotFound, RoutingError, i jako msg przekazuje jakies dane odpowiednio NazwaKlasy + id, nazwa pliku, parametry requestu. Rozpoznawanie po kodzie bledu jest lipne, bo musisz dopisac funkcjonalnosc ktora juz masz [obsluge wielu catch'y], zamiast po prostu utworzyc kilka klas wyjatkow [1000x czytelniejsze] -------------------- Nie lubię jednorożców.
|
|
|
Wersja Lo-Fi | Aktualny czas: 31.05.2024 - 16:01 |