Действительные варианты использования для at-sign в php

Знак at используется для скрытия сообщений об ошибках. Насколько я вижу, нет абсолютно никакого случая или оправдания для его использования.

  1. Вы можете скрыть ошибки в производстве, изменив настройки php ini, все еще выводя ошибки в файлы журнала
  2. @ -sign мешает программистам-программистам определить, где проблема
  3. Сообщения об ошибках являются вашими друзьями при разработке. Быстро найти ошибки и исправить их

Один мой друг потратил пару часов, пытаясь выяснить, почему программное обеспечение работает в одной системе, а не на другом. Это заняло бы около 10 секунд, если бы разработчик библиотеки не использовал @ -sign.

Я близкий, когда говорю, что нет никакой ценности для @ -знания, есть ли действительный случай?

Related of "Действительные варианты использования для at-sign в php"

Для знака @ есть некоторая ценность, но обычно это запах кода.

Рассмотрим следующее: вы разрабатываете библиотеку, которая должна быть совместима с несколькими проектами, и вы не хотите менять обработчик ошибок по всему миру. К сожалению, многие функции PHP (включая сокеты и связанные с потоками) генерируют ошибку PHP, а не исключение при сбое. Знак «@» тогда полезен для скрытия ошибки тогда и только тогда, когда ошибка затем проверяется вручную, и исключение генерируется, если оно произошло.

Это также полезно для операций с файловой системой.
В основном вы правы, хотя … это обычно ужасная практика (:

Есть несколько редких ситуаций, когда действительно имеет смысл использовать подавление ошибок.

Один из них – операции с атомной файловой системой. Например, вместо написания

 if (file_exists($fileName)) { unlink($fileName); } 

вы просто делаете

 @unlink($fileName); 

Это гарантирует, что ваш код не будет подвержен условиям гонки.

Обычно @ полезно в ситуациях, когда PHP выбрал неподходящую модель ошибки для функции. Вышеупомянутая функция unlink является одним из таких примеров. Аналогичным образом существуют и другие функции, в которых PHP генерирует ошибки, хотя и не должен (вместо этого использовать возвращаемые значения или захватывающие исключения).

В большинстве случаев вы не должны его использовать. В некоторых случаях это имеет смысл:

  • unlink()
  • while (@ob_end_flush());

Могут быть и другие крайние случаи, но помимо этого вы никогда не должны никогда недовольны ошибками.

Как и все доступные инструменты (как в программировании, так и вне его), все имеет законный прецедент.

Первый пример, который приходит на ум для оператора подавления ошибок, будет чем-то вроде

 if (!@unlink($file)) { // I am already handling the error. I don't care what caused it. // Even NOT handling this case at all could be a legitimate reaction // depending on circumstances. } 
  • При использовании DOMDocument неверный HTML выдаст предупреждения, в большинстве случаев нас не волнует.
  • При использовании Mail PEAR вы получите предупреждения о функциях, которые не следует называть статически, потому что Mail поддерживает PHP 4. Их можно безопасно игнорировать.
  • При использовании unlink() вы подавляете ошибки, чтобы предотвратить условия гонки.

Наиболее распространенное место, которое я видел, используется для подавления ошибок mysql при работе с db. Затем пользователь проверяет ответ и выводит соответствующее сообщение об ошибке.

пример

 <?php $link = @mysql_connect('localhost', 'mysql_user', 'mysql_password'); if (!$link) { die('Could not connect: ' . mysql_error()); } echo 'Connected successfully'; mysql_close($link); ?> 

Я также видел, что он использовался при работе с ftps и sftps.

Но я согласен с вами в том, что я считаю, что его использование ограничено. Если кто-то окажется в ситуации, когда вы чувствуете необходимость использовать @ -знак в собственном выпуске кода, я думаю, что пришло время переосмыслить решение.