Kiedy funkcja @ staje się przydatna?

Question

Jak wiesz, znaki @ przed phpstrukcją powstrzymują każde ewentualne ostrzeżenie, błąd lub zawiadomienie przed podniesieniem.

Osobiście nie podoba mi się ta tecnique, bo wolę poradzić sobie z tymi błędami, aw prawdziwym życiu błąd nie może się zdarzyć lub trzeba nim zarządzać.

Przy okazji, uważam, że ta tecnique ma zastosowanie w wielu skryptach (wtyczki cms, klasy open-source).

Czy zatem @ może być naprawdę użyteczny (w tym przypadku przykład zostanie doceniony), czy może jest po prostu dla leniwych programistów?

Answer 1

Pomyśl na przykład o nieudanym połączeniu mysql_connect. Możesz w tym przypadku zignorować komunikat o błędzie, który został pokazany użytkownikowi (pokazując również pewne szczegóły, których zwykle nie chcesz widzieć).

Mimo że ostrzeżenie PHP zostało wyłączone poprzez znak-@, można wykonać pewne czynności, takie jak wyświetlanie przyjaznego komunikatu o błędzie użytkownikowi.

jednak „nadużywanie” @ rzeczy jak w poniższym przykładzie na pewno nie jest dobrym pomysłem:

@$undefinedVariable .= 'some text'; 

Istnieje znacznie więcej przykładów złego używania oznaczenia błędów tłumienia tam niż jeden powyżej , powinieneś go używać tylko wtedy, gdy nie ma innego, lepszego sposobu na osiągnięcie tego, co chcesz.

Answer 2

Naprawdę nie lubię @, ale czasami w niektórych konfiguracjach jest to nieuniknione.

Osobiście wolę ustawić PHP w konfiguracji, aby po prostu rejestrować błędy i bezgłośnie przerywać konfiguracje produkcyjne, zamiast używać kuli @ do tłumienia wiadomości.

Dobre wykorzystanie: ostrzeżenia. Czasami funkcje wyświetlają ostrzeżenia i po prostu nie ma nic, co można zrobić bez przeprojektowania, ale nadal działa poprawnie. @ powstrzyma to.

Answer 3

Odpowiedź na twoje pytanie jest prosta i bezpośrednia: nie, @ jest bezużyteczna, aw rzeczywistości szkodliwa i nie powinna być używana. Nigdy.

Jedyny wyjątek, jaki mogę wymyślić, to szybkie skrypty "run-once", kiedy naprawdę nie zależy Ci na jakości i poprawności kodu.

w skryptach produkcyjnych, polecam korzystania set_error_handler który konwertuje błędów do wyjątków i try z pustym catch bloku w rzadkich przypadkach, gdy błąd powinno być ignorowane:

try { 
    unlink('tempfile'); 
} catch(Exception $e) { 
    // i don't care 
} 

Answer 4

Jest jeden przypadek użycia: Jeśli chcesz przetestować scream, rozszerzenie PECL, które wyłącza operatora @. :)

Answer 5

Jestem trochę spóźniony, ale używanie @ w PHP zazwyczaj nie jest dobrym pomysłem. Używałbym go tylko do kodu testowego i na pewno nie do produkcji.

Znacznie lepszym sposobem postępowania z błędami jest użycie funkcji set_error_handler (http://ch.php.net/set_error_handler). Jeśli coś pójdzie nie tak, możesz po prostu zarejestrować błąd (i może powiadomić administratora), a następnie wyświetlić niestandardowy komunikat o błędzie dla użytkownika lub możesz go zignorować, jeśli jest to tylko ostrzeżenie/ostrzeżenie. (Prawdopodobnie już to robisz.)

I tu znowu przyda się @. Jeśli do polecenia zostanie dołączony @ i spowoduje to jakikolwiek błąd, procedura obsługi błędów będzie mimo wszystko wywoływana, ale z parametrem "errno" ustawionym na zero. Spójrz na listę różnych wartości poziomów błędów php (http://ch.php.net/manual/en/errorfunc.constants.php). Żadna z nich nie jest równa zero, więc można zidentyfikować błędy, które wystąpiły w funkcjach z poprzedzającym @. Możesz na przykład użyć go do "oznaczania" nieistotnych błędów (gdy nie chcesz przerwać wykonywania, ale mimo to upewnij się, że logujesz się, ponieważ może to być przydatne do debugowania) lub użyj go do jakiegoś innego celu.

Answer 6

Jedyna sytuacja przydatne byłoby:

jeśli nie masz dostępu do php/apache config i błędy są wyświetlane użytkownikowi.

W przeciwnym razie NIGDY nie używaj @... i nie przekierowuj błędów (w konfiguracji php/apache) do niektórych systemów logów (plików, baz danych itp.).

PS: W niektórych oficjalnych dokumentach PHP widać, że zamiast sprawdzać, czy plik istnieje, a następnie usuwa go, to po prostu @unlink to. Ale to mi się nie podoba: wolę błąd w dziennikach na wypadek wydania (prawa dostępu itp.).