Когда делает, становятся полезными?
Как Вы знаете, @ символы перед php istruction подавляют каждое возможное предупреждение, ошибку или замечают от того, чтобы быть повышенным.
Лично, мне не нравится эта техника, becose я предпочитаю обрабатывать те ошибки, и в реальной жизни, ошибка должна не происходить или должна управляться.
Между прочим, я нахожу, что эта техника применяется во многих сценариях (cms плагины, классы с открытым исходным кодом).
Так, мог действительно быть полезным (в этом случае, пример будет цениться), или только для ленивых разработчиков?
6 ответов
Подумайте, например, о неудачном вызове mysql_connect . В этом случае вы можете захотеть подавить сообщение об ошибке, которое в противном случае показывалось бы пользователю (также показывая некоторые детали, которые вы обычно не хотите, чтобы кто-либо видел).
Хотя предупреждение PHP было подавлено с помощью знака @ , вы можете выполнять определенные действия, например, показывать пользователю понятное сообщение об ошибке впоследствии.
Однако «неправильное использование» @ для таких вещей, как в примере ниже, определенно не является хорошей идеей:
@$undefinedVariable .= 'some text';
Существует гораздо больше примеров неправильного использования знака подавления ошибок, чем один выше, вы должны использовать его только тогда, когда нет другого, лучшего способа достичь того, чего вы хотите.
Есть один вариант использования: если вы хотите протестировать scream , расширение PECL, которое отключает оператор @. :)
Ответ на ваш вопрос прост и прямолинеен: нет, @ бесполезен, а на самом деле вреден и не должен использоваться. Никогда.
Единственное исключение, о котором я могу думать, - это быстрые сценарии с однократным запуском, когда вы действительно не заботитесь о качестве и правильности кода.
В производственных сценариях я бы предложил использовать set_error_handler , который преобразует ошибки в исключения, и попробуйте с пустым блоком catch в редких случаях, когда должна возникать ошибка. игнорировать:
try {
unlink('tempfile');
} catch(Exception $e) {
// i don't care
}
Я немного опоздал, но использование @ в PHP обычно не является хорошей идеей. Я бы использовал его только для тестового кода, но не для продакшена.
Намного лучший способ обработки ошибок - использование функции set_error_handler ( http://ch.php.net/set_error_handler ).Если что-то пойдет не так, вы можете просто зарегистрировать ошибку (и, возможно, уведомить администратора), а затем отобразить настраиваемое сообщение об ошибке для пользователя или вы можете просто проигнорировать его, если это всего лишь уведомление / предупреждение. (Вероятно, вы это уже делаете.)
И здесь снова пригодится @ . Если вы добавите @ к команде, и это вызовет ошибку любого типа, обработчик ошибок будет вызван в любом случае, но с параметром 'errno', установленным в ноль. Взгляните на список различных значений уровней ошибок php ( http://ch.php.net/manual/en/errorfunc.constants.php ). Ни один из них не равен нулю, поэтому вы можете идентифицировать ошибки, которые произошли в функциях, с добавлением @ . Вы можете, например, использовать его для «пометки» неважных ошибок (когда вы не хотите прерывать выполнение, но в любом случае обязательно регистрировать их, так как это может быть полезно для отладки) или использовать его для других целей.
Мне действительно не нравится @ , но иногда в некоторых настройках этого невозможно избежать.
Лично я предпочитаю настраивать PHP в конфигурации так, чтобы он просто регистрировал ошибки и автоматически выходил из строя при производственных настройках, а не использовал костыль @ для подавления сообщений.
Хорошее применение: предупреждения. Иногда функции выдают предупреждения, и вы ничего не можете сделать без редизайна, но все равно работает правильно. @ подавит его.
Единственная полезная ситуация:
если у вас нет доступа к php/apache config и ошибки отображаются пользователю.
В противном случае НИКОГДА не используйте @... и перенаправляйте ошибки (в конфигурации php/apache) в какую-либо систему регистрации (файл, базу данных и т.д.).
PS: В некоторой официальной документации по PHP можно увидеть, что вместо того, чтобы проверять, существует ли файл, а затем удалять его, они просто @unlink его. Но мне это не нравится: Я предпочитаю получать ошибку в журналах в случае возникновения проблемы (права доступа и т.д.).