![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Zarejestrowani Postów: 251 Pomógł: 2 Dołączył: 24.08.2005 Ostrzeżenie: (0%) ![]() ![]() |
Witam, przyklad pierwszy zwraca Nottce'a. Mozna sie przed nim 'zabezpieczyc' stosujac ktorych z nastepnych dwoch sposobow.... Ale czy warto pisac aplikacje uzywajac tych 'zabezpieczen' aby chodzila bezblednie na pelnym raportowaniu bledow, czy dac sobie spokoj?? Jakie jest Wasze zdanie?? |
|
|
![]() |
![]()
Post
#2
|
|
![]() Grupa: Zarejestrowani Postów: 65 Pomógł: 9 Dołączył: 30.06.2009 Ostrzeżenie: (0%) ![]() ![]() |
Zależy od strony. Jak jakiś mały blog, albo coś malutkiego to w sumie nie wiem czy warto. Przy większych projektach na pewno warto. Tam jeden błąd może posypać cały serwis.
|
|
|
![]()
Post
#3
|
|
![]() Grupa: Zarejestrowani Postów: 2 592 Pomógł: 445 Dołączył: 12.03.2007 Ostrzeżenie: (0%) ![]() ![]() |
Błędy notice można ignorować, są to, jak sama nazwa wskazuje tylko powiadomienia. Czyli małe wskazówki informujące np o tym, żeby przed wyświetleniem zawartości zmiennej najpierw sprawdzić czy ta zmienna istnieje itd. W wielu przypadkach jest to zbędne, powoduje tylko nadmiarowość kodu. Czasem owszem, można coś zauważyć wartego poprawy.
Co innego inne, te już trzeba obsłużyć, ich się nie ukrywa poprzez użycie @. Dlatego w środowisku testowym (w przeciwieństwie do finalnego) raportowanie błędów należy włączyć (niekoniecznie z E-NOTICE). -------------------- |
|
|
![]()
Post
#4
|
|
![]() Grupa: Zarejestrowani Postów: 1 387 Pomógł: 273 Dołączył: 18.02.2008 Ostrzeżenie: (0%) ![]() ![]() |
Problemy tego typu znikają po napisaniu swojej klasy do obsługi takich zmiennych, w której przewiduje się przypadek ich nieistnienia
![]() A używanie niezadeklarowanych zmiennych to bardzo zły nawyk... -------------------- XMPP: l0ud@chrome.pl
|
|
|
![]()
Post
#5
|
|
![]() Grupa: Zarejestrowani Postów: 952 Pomógł: 154 Dołączył: 20.01.2007 Skąd: /dev/oracle Ostrzeżenie: (0%) ![]() ![]() |
Na pewno warto raportowanie błędów E_NOTICE mieć włączone. Choć PHP teoretycznie dopuszcza odwołania do nieistniejących zmiennych, w dobrze napisanym kodzie nieistniejące zmienne pojawiają się w 99% przypadków wskutek pomyłki/literówki podczas pisania. Odwołania do nieistniejących elementów tablicy w większości przypadków wynikają z zapomnienia o uwzględnieniu warunków brzegowych lub pomyłki przy pisaniu algorytmu. Odwołania do nieistniejących pól obiektu przy braku zdefiniowanych metod __get() oraz __set() to błąd w sztuce
![]() Jak widać, nie są to błędy same w sobie, ale najczęściej są wynikiem błędów podczas programowania/implementacji, co oznacza, że zdecydowanie nie powinny one się w ogóle pojawiać. W szczególności karygodne jest, aby pojawiały się one przy odwołaniach do tablic $_GET/$_POST itd. - jest to wręcz zaproszenie do próby włamania się do serwisu, już nie wspominając o tym, że ujawniają one wewnętrzne ścieżki systemowe, co z kolei może być pomocne przy próbie włamania się na serwer. Pamiętanie o sprawdzaniu istnienia zmiennych oraz definiowaniu ich początkowej wartości należy do dobrych zwyczajów i pozwala pisać bardziej idiotoodporny kod. Zwracam tu uwagę, że nie trzeba we wszystkich możliwych miejscach wstawiać if(isset()) itd., lecz po prostu myśleć. W dobrze napisanym systemie o jasnym przepływie sterowania można sobie bardzo ułatwiać życie korzystając z faktu, że jeśli coś sprawdzimy na początku jakiegoś kawałka kodu, to możemy mieć pewność, że w dalszej jego części będzie to dalej spełnione. Na dodatek dzięki temu możemy wykorzystać E_NOTICE w jeszcze lepszym celu. Jeśli gdzieś się pojawi, traktujemy to jako błąd podczas programowania (jakaś niejasność w kodzie, luka lub przejście, które łamie zasady) i już na etapie tworzenia kodu możemy dążyć do jego wyeliminowania. W moim kodzie do nieistniejących zmiennych wolno odwoływać się tylko po spełnieniu zespołu warunków: 1. Doskonale wiemy, co robimy i mamy świadomość konsekwencji. 2. Nie ma innej, eleganckiej możliwości wyrażenia tego samego. 3. Obniżymy poziom raportowania błędów przez error_reporting(), a po wyjściu z sekcji krytycznej przywrócimy poprzedni. 4. Odwoływanie się dotyczy zmiennych, które są w całości wytworem skryptu, nigdy - danych pochodzących z żądania HTTP lub w jakikolwiek inny sposób z zewnątrz. W praktyce taka sytuacja wystąpiła u mnie RAZ. Ten post edytował Zyx 30.11.2009, 19:06:30 -------------------- Specjalista ds. głupich i beznadziejnych, Zyx
Nowości wydawnicze: Open Power Collector 3.0.1.0 | Open Power Autoloader 3.0.3.0 |
|
|
![]()
Post
#6
|
|
Grupa: Zarejestrowani Postów: 251 Pomógł: 2 Dołączył: 24.08.2005 Ostrzeżenie: (0%) ![]() ![]() |
Tak wiec, jezeli chce pobrac wartość z ciastka i sprawdzic czy nalezy do prawidlowych wartosci z tablicy co bedzie lepsze:
to pierwsze krotsze czyli bardziej przejrzyste, ale nie wiem czy to dobra maniera stosowac w kodzie @. Kwestia jeszcze co jest szybsze (zaraz to sprawdze). Swoja dorga podoba mi sie np JS. Tam wszelakie nieprzypisane wartosci tablic, obiektow zwracaja undefined i nie mamy do czynienia z zadnymi Errorami/Noticami. Po prostu sprawdzamy czy jest undefined i tyle.... W wiekszosci przypadkow ustalona wartosc rzutuje sie na true, a undefined na false, wiec kontrola jest dziecinnie prosta. Własciwie przy uzyciu @ w PHP mozna postepowac tak samo. Ten post edytował kufalo 30.11.2009, 20:05:07 |
|
|
![]()
Post
#7
|
|
![]() Grupa: Zarejestrowani Postów: 952 Pomógł: 154 Dołączył: 20.01.2007 Skąd: /dev/oracle Ostrzeżenie: (0%) ![]() ![]() |
O istnieniu operatora @ najlepiej zapomnieć w ogóle. Nie dość, że jest on powolny, to jeszcze ukrywa wszystkie błędy, jakie są możliwe w PHP. To jest jedyna prawdziwie poprawna forma.
Pierwsze niekoniecznie jest bardziej przejrzyste i na dodatek może zadziałać niezgodnie z Twoimi oczekiwaniami. Sprawdź sobie działanie poniższego kodu z niezainicjowanym $_GET['foo']:
Hehe, nic nie ustawiamy, a nam warunek 1 uznaje za spełniony. PHP w przypadku niezainicjowanych zmiennych generuje dla nich specjalną wartość null. Przypuśćmy, że ten kod jest jakimś zabezpieczeniem serwisu i wskutek literówki w tablicy dozwolonych wartości znalazł się null, a na jej podstawie przyznawany jest dostęp do jakiejś operacji. Puszasz serwis do Internetu i po pewnym czasie ktoś odkrywa, że jak skasuje sobie zmienną z adresu, to zabezpieczenie opada i zaczyna to bezlitośnie wykorzystywać, a ty płacesz, bo ktoś się włamuje. Ja jestem mądry i mam wbite do głowy, że istnienie zmiennych sprawdza się przez isset(). Ponadto dzięki eliminowaniu błędów E_NOTICE na etapie tworzenia wiem od razu, że zrobiłem literówkę i problemu nie mam, a gdyby nawet coś pozostało niezauważone, to na pewno nikt mi nie będzie robić kuku przez zwykłe skasowanie zmiennej w adresie bądź ciastka. Zrozum, że przyrównywanie wartości do nulla to nie jest żadna kontrola, szczególnie jak nie ma się do końca pojęcia, jak coś działa. Każdy szanujący się programista po prostu sprawdza warunki brzegowe i inicjuje zmienne przed użyciem, a nie szuka dróg na skróty, bo mu się nie chce paru dodatkowych linijek wklepać, a później się dziwi, że mu się strona sypie. W Javie to by się taki kod nawet nie skompilował, albo rzucał Ci wyjątkiem, bezlitośnie przypominając, że olewanie kontroli danych mści się później okrutnie. Ten post edytował Zyx 30.11.2009, 20:45:29 -------------------- Specjalista ds. głupich i beznadziejnych, Zyx
Nowości wydawnicze: Open Power Collector 3.0.1.0 | Open Power Autoloader 3.0.3.0 |
|
|
![]()
Post
#8
|
|
Grupa: Zarejestrowani Postów: 73 Pomógł: 4 Dołączył: 13.01.2004 Skąd: Bielsko-Biała Ostrzeżenie: (0%) ![]() ![]() |
dla mnie też - notice = błąd w skrypcie
jedynie w jednym miejscu gdzie generuje spoooore statystki oparte na bazie mam dorzucone @ przed operacją na jednej wielowymiarowej tablicy - tablica ma ileśset tysięcy rekordów i mogą zdarzyć się nieustawione elementy, inicjalizacja tej tabeli -aby wszystkie pola na pewno były dla każdego indeksu lub sprawdzanie czy istnieje dany indeks wydłużało działanie skryptu dobre 2 razy - więc poprostu wrzuciłem @ przed ![]() moje 2 grosze:P -------------------- gragieldowa.pl
|
|
|
![]()
Post
#9
|
|
![]() Grupa: Zarejestrowani Postów: 2 592 Pomógł: 445 Dołączył: 12.03.2007 Ostrzeżenie: (0%) ![]() ![]() |
Pominięcie sprawdzania istnienia elementu można usprawiedliwić przy sprawdzaniu jego wartości. Przykładowo:
Ale oczywiście w konkretnych przypadkach. Czasem ważne jest sprawdzenie czy zmienna w ogóle istnieje, niekoniecznie czy posiada przypisaną wartość. Tak czy inaczej wszelkie operacje na zmiennych powinny być poprzedzone ich sprawdzeniem pod kątem istnienia, wartości, prawidłowego typu. -------------------- |
|
|
![]()
Post
#10
|
|
![]() Grupa: Zarejestrowani Postów: 259 Pomógł: 42 Dołączył: 8.04.2005 Skąd: Mława Ostrzeżenie: (0%) ![]() ![]() |
Podpisuję się pod tym, że to błąd w sztuce.
Jeśli ktoś zaczyna naukę od PHP, takie niechlujstwo może wejść w krew. Jeśli zaczynamy przygodę z PHP ze znajomością języka kompilowanego, takie podejście razi. Podsumowując, tak czy inaczej, jestem za eliminowaniem notice'ów. -------------------- |
|
|
![]()
Post
#11
|
|
![]() Grupa: Moderatorzy Postów: 4 362 Pomógł: 714 Dołączył: 12.02.2009 Skąd: Jak się położę tak leżę :D ![]() |
Ja zacząłem przygodę z programowaniem od Turbo Pascala. Po paru perturbacjach (czytaj: między innymi AC Logo
![]() -------------------- Najpierw był manual... Jeśli tam nie zawarto słów mądrości to zapytaj wszechwiedzącego Google zadając mu własciwe pytania. A jeśli i on milczy to Twój problem nie istnieje :D
|
|
|
![]() ![]() |
![]() |
Aktualny czas: 21.08.2025 - 04:28 |