Когда @ становится полезным?

Question

Как вы знаете, символы @ до того, как php istruction подавляет все возможные предупреждения, ошибки или уведомления от повышения.

Лично мне не нравится этот tecnique, потому что я предпочитаю обрабатывать эти ошибки, и в реальной жизни ошибка не должна произойти или должна управляться.

Кстати, я нахожу, что это приложение применяется во многих сценариях (cms-плагины, классы с открытым исходным кодом).

Итак, может ли @ действительно быть полезным (в данном случае, пример будет оценен) или просто для ленивых разработчиков?

Answer 1

Просто подумайте, например, о неудавшемся вызове mysql_connect. Возможно, вы захотите подавить сообщение об ошибке, которое в противном случае было бы показано пользователю (также показывающее некоторые детали, которые, как правило, не хотят, чтобы кто-либо еще видел) в этом случае.

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

Однако «злоупотребляет» @ для таких вещей, как в приведенном ниже примере, безусловно, не является хорошей идеей:

@$undefinedVariable .= 'some text'; 

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

Answer 2

Мне очень не нравится @, но иногда в некоторых настройках это неизбежно.

Лично я предпочитаю устанавливать PHP в конфигурации, чтобы просто регистрировать ошибки и тихо работать на производственных настройках, а не использовать костыль @ для подавления сообщений.

Полезное использование: предупреждения. Иногда функции бросают предупреждения, и просто нечего делать без редизайна, но он по-прежнему работает правильно. @ подавит его.

Answer 3

Ответ на ваш вопрос прост и прям: нет, @ бесполезен, а на самом деле вреден и не должен использоваться. Никогда.

Единственное исключение, о котором я могу думать, - это быстрые сценарии «run-once», когда вы действительно не заботитесь о качестве и правильности кода.

В производственных сценариях, я предлагаю использовать set_error_handler, который преобразует ошибки в исключение, и try с пустым catch блока в редких случаях, когда ошибку следует игнорировать:

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

Answer 4

Там один случай использования: Если вы хотите проверить scream, расширение PECL, которое отключает оператор @. :)

Answer 5

Я немного опоздал, но с использованием @ в PHP, как правило, не очень хорошая идея. Я бы использовал его только для тестового кода и, конечно, не для производства.

Гораздо лучший способ обработки ошибок - использовать функцию set_error_handler (http://ch.php.net/set_error_handler). Если что-то пойдет не так, вы можете просто зарегистрировать ошибку (и, возможно, уведомить администратора), а затем отобразить пользовательское сообщение об ошибке для пользователя или просто проигнорировать его, если это только уведомление/предупреждение. (Вероятно, вы уже это делаете.)

И вот тут снова пригодится @. Если вы добавите команду @ к команде и она вызывает какую-либо ошибку, обработчик ошибок будет вызван в любом случае, но с параметром «errno», установленным на ноль. Посмотрите на список различных значений уровней ошибок php (http://ch.php.net/manual/en/errorfunc.constants.php). Ни один из них не равен нулю, поэтому вы можете идентифицировать ошибки, возникающие в функциях с добавлением @. Например, вы можете использовать его для «флага» несущественных ошибок (когда вы не хотите прервать выполнение, но обязательно зарегистрируйте его в любом случае, поскольку это может быть полезно для отладки) или использовать его для каких-либо других целей.

Answer 6

Единственная полезная ситуация была бы:

, если у вас нет доступа к PHP/Apache конфигурации и ошибки отображаются для пользователя.

В противном случае НИКОГДА не используйте @... и перенаправляйте ошибки (в конфигурации php/apache) в систему регистрации (файл, базу данных и т. Д.).

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