@ zamiast isset() Opcje

[norgoth]

Mam w swoim projekcie kilka takich kilka takich struktur kontrolnych, gdzie właściwie nie interesuje mnie czy dana zmienna istnieje czy nie, bo jeśli nie istnieje, to i tak warunek nie będzie spełniony, czyli mam rezultat jakiego chce.

Jako przykład mogę podać walidację formularza, w przypadku kiedy użytkownik nie wpisał jakichś potrzebnych danych, a formularz i tak nie przejdzie bo dane są sprawdzone pod kątem minimalnej długości stringa a np. długość nie może być mniejsza niż 5.

Problem w tym że kiedy tej zmiennej nie ma, to w error.log powstają niepotrzebne notice.

No i teraz pytanie. Czy można tłumić te notice przez dodanie przed zmienną operatora @, czy może mogą powstać jakieś niepoźądane efekty takiego działania i lepiej było by sprawdzać zmienną przez isset()? Jednak znowu czy isset() nie jest większym obciążeniem dla aplikacji niż małe, szybkie @?

Ten post edytował norgoth 31.01.2008, 23:44:06

[mike]

Jeśli spadek szybkości nawet do 30% jest dla Ciebie rzeczą do przełknięcia to możesz korzystać z @
Operator ten tłumi wyświetlanie, i tylko i wyłącznie wyświetlanie.

Dla parsera PHP to się nie liczy. On i tak zwraca błąd, przetwarza go i generuje. Ty tego po prostu nie widzisz, ale parser PHP i tak musi to zrobić. Co za tym idzie - poświęcić na to czas.

isset() jest za to składową języka (jedną z jego konstrukcji) więc działa dużo szybciej niż dowolna funkcja, zadecydowanie szybciej niż korzystanie z @

Poza tym stosując @ nie pozbywasz się błędów (bo generowany NOTICE to w rzeczywistości raport że coś jest nie tak), Ty je po prostu ukrywasz. A błędy należy naprawiać a nie chować pod dywan.

P.S.
@ to się tylko szybko pisze na klawiaturze Rezultaty jego działania wcale nie są szybkie

[norgoth]

Tego się właśnie obawiałem. A wyglądało tak pięknie i czytelnie

[sobstel]

1. możesz ustawić error_reporting bez NOTICE, ale to rozwiązanie na szybko dla gotowego skryptu, zdecydowanie od razu lepiej pisać bez jakichkolwiek błędów

2. @mike, jesteś pewny, że przy @ parser zwraca błąd, przetwarza go i generuje?
w jakiejś prezentacji jednego z developerów (był to chyba Ilia Alshanetsky) wyczytałem, że PHP wykonuje następujące instrukcje:

[PHP] pobierz, plaintext 
<?php
$default = error_reporting(0);
// wykonanie instrukcji
error_reporting($default);
?>
[PHP] pobierz, plaintext 

i że to właśnie to przełączanie error_reporting jest tak kosztowne. błędy nie są generowane bo error_reporting jest 0.

Ten post edytował sopel 1.02.2008, 00:57:02

[mike]

2. @mike, jesteś pewny, że przy @ parser zwraca błąd, przetwarza go i generuje?

Sprawdziłem teraz i faktycznie przy użyciu @ komunikaty nie są zapisywane do plików logów. Co oznaczałoby, że PHP ich nie przesyła dalej.
Nie mniej jednak nadal uważam, że parser te błędy generuje a potem przechwytuje. Czytałem to w którejś z książek a później obił mi się o "uszy" jakiś benchmark znaleziony w sieci.
Zwróć uwagę, że error_reporting() z zerem jako parametr sprawi, że błędy nie zostaną zaraportowane a nie, że nie zostaną przechwycone. Faktycznie może być tak, że skorzystanie z operatora tłumienia powoduje przełączanie tej dyrektywy.

Nie mniej jednak na pewno jest to opóźnienie.

[sobstel]

To, że jest to opóźnienie, to nie ulega wątpliwości.

Co do drugiej części, w sumie przecież @ są także obsługiwane przez własny handler (ustawiony przez set_error_handler()), wystarczy wewnątrz handlera sprawdzić czy error_reporting() zwraca 0 (co z kolei potwierdza moją wersję zdarzeń z przestawianiem error reportingu ;-) ), czyli podsumowując błędy są przechwytywane, ale standardowy mechanizm ich nie raportuje (loguje).