После того, как у меня есть аргумент с моей командой, потому что у всех нас разные взгляды на такую ситуацию. Когда действительно приемлемо отключать сообщения об ошибках PHP или подавлять некоторые функции, которые бросают предупреждения, уведомления по любой причине ..
Я понимаю, что каждый говорит, что вы должны отключить error_reporting в рабочей среде, но это может привести к некоторым осложнениям, которые не будут подняты. Таким образом, ничто не будет исправлено. PHP использует множество различных методов для управления сообщениями об ошибках. Например:
$Var = "Variable Is Set"; if (@$Var){ echo $Var; } Над:
if (isset($Var)){ echo $Var; }
Поскольку у нас есть заданная переменная, это будет успешно эхо. Если бы у нас не было заданной переменной, это бы бросило уведомление. Так какой из них использовать? Иссете или подавление ошибок?
И в производственной среде, какой из них будет более приемлемым?
error_reporting(0);
Вышеупомянутое отключит все типы отчетов об ошибках PHP, не выдавая сообщений об ошибках, даже если что-то встречается. Поэтому в некоторых случаях это может привести к поломке кода, который перестает работать по неизвестной причине из-за разрушения сообщения
или:
set_error_handler("");
Вышеприведенный способ позволяет использовать специальный обработчик ошибок, который может использоваться для изящного отображения ошибки пользователю и позволяет администратору регистрировать подробное предупреждение. Но опять же, error_handler, насколько мне известно, не будет вызываться при возникновении фатальной ошибки ?
Итак, мой общий вопрос?
Обработать ошибки в рабочей среде или просто отключить их вообще? Это сводится к лучшим практикам и предпочтениям, которые я предполагаю. Но это то, что озадачивает меня и мою команду до разногласий.
Извините, это не определенное решение, но после нескольких лет проб и ошибок я придумал следующие практики, которые являются моими собственными, и работают очень хорошо:
1 – Никогда не используйте @ для подавления ошибок. Никогда не используйте ничего, чтобы слепо скрывать или игнорировать все ошибки. ВСЕ ошибки важны, никакая ошибка не должна игнорироваться.
2 – Сделайте, как предлагал Рафасаси, включите регистрацию ошибок и отключите ошибки отображения.
3 – Активируйте ВСЕ отчет об ошибках, используя error_reporting = 2147483647 в PHP.INI. Это сделает PHP очень придирчивым к чему-либо, что вы можете сделать неправильно, помогая вам узнать больше и не отставать от будущих языковых разочарований и изменений.
4 – Вы также можете создать собственное ведение журнала ошибок, чтобы точно записывать то, что вы хотите, так, как вы хотите. Посмотрите руководство для error_log() . Если вы его используете, вы можете даже отключиться и начать вручную, что даст вам полный контроль над системой регистрации ошибок PHP.
5 – Я использую ООП во всем моем PHP-коде, поэтому я использую исключения во всем мире, и я рекомендую то же самое для всех. Они на много лет опережают просто обработку ошибок. Используйте этот код, чтобы перехватить все ошибки в вашем коде и выбросить их как исключения:
set_error_handler('ErrorHandler'); function ErrorHandler($Code, $Message) { throw new Exception($Message, $Code); }
6 – Не показывать ЛЮБЫЕ ошибки пользователю просто не имеет смысла. Должны быть показаны некоторые ошибки, некоторые должны быть скрыты, а некоторые должны отображаться как общая проблема (не говорите пользователю, в чем именно проблема).
a) Ошибки, которые должны быть показаны: все, вызванное пользователем, например неправильный ввод формы или неправильное поведение. Это совершенно очевидно, но следует упомянуть.
b) Ошибки, которые должны быть скрыты: скрыть только те ошибки, которые ваш код может обрабатывать и исправлять. Например, вы можете подключиться к БД, и если это не удается, вы можете попробовать еще раз. Если вторая попытка удалась, идите вперед, никто не должен знать, что первая попытка не удалась. Просто зарегистрируйте его, если хотите, используя error_log() . Иногда переменные еще не существуют, поэтому проверьте это с помощью isset() и при необходимости инициализируйте их. Не нужно сообщать об этом как об ошибке.
c) Ошибки, которые должны отображаться как общие: большинство ошибок попадают в эту категорию. Вы не будете показывать пользовательские вещи, например, из-за нехватки памяти PHP, или что SMTP-сервер отключен, или что соединение с БД было отклонено. Просто узнайте, как обернуть опасный код с помощью try , использовать catch для захвата любой ошибки и преобразовать сообщение в то, что вы можете показать пользователю. Пример:
try { // Dangerous code ahead: we will try to connect to the database, but it // can be offline. $mysqli = new mysqli("localhost", "user", "password", "database"); } catch(Exception $e) { // If we're here, something bad happened during connection. Let's handle it. // Notify staff, log error, do anything you can to get someone to quickly // check the issue. SendMailAdmin("Database connection Error, check ASAP."); error_log("Database connection Error, check ASAP."); // And show the user some message. You don't need to tell him about any // detail regarding what truly caused the error. die("A problem occurred in our servers. Our technical staff has been notified, please try again in a few minutes."); } // If we're here, everything worked fine, so do your DB query and so on....
Вместо die() вы можете использовать то, что считаете нужным: перебросить в качестве другого исключения, перенаправить заголовок на общее сообщение об ошибке или что угодно.
7 – Это более продвинутый, но вы также можете это сделать: создать свою собственную иерархию исключений, например:
class MVXException extends Exception {} class ExMVXDB extends MVXException {} class ExMVXDBRead extends ExMVXDB { } class ExMVXDBWrite extends ExMVXDB { } class ExMVXDBNotFound extends ExMVXDB { }
Это упрощение дерева исключений, которое у меня есть в моей самодельной структуре. Красота этого заключается в том, что если вы catch(ExMVXDB $e) , вы поймаете ВСЕ ошибки БД. Но если вы хотите поймать только операцию записи данных, вы можете сделать catch(ExMVXDBWrite $e) .
Вот и все. Обработка ошибок не проста, и нет прямого ответа, но есть множество инструментов и хороших практик, которые помогут вам выбрать то, что лучше для вас.
Вы никогда не просто полностью отключите отчет об ошибках. Вы отключите отображение ошибок . Непосредственные ошибки сброса на экран необходимы во время разработки (если только у вас нет других методов, которые бросают все ошибки на вашем лице), в процессе производства вы хотите получать одинаковые сообщения об ошибках, но вместо того, чтобы выводить видимые ошибки, вы хотите, чтобы они регистрировали их только. Все это можно сделать с помощью настроек конфигурации отчетов об ошибках PHP.
Если вам нужна специальная обработка ошибок / ведение журнала, используйте специальный обработчик ошибок.
Что касается @ , вы никогда не пишете свое приложение таким образом, чтобы он производил фактические ошибки, на поведение которых вы полагаетесь. Вы пишете все так, чтобы не приводить к ошибкам. Вы используете только @ когда нет возможности избежать возможной ошибки, потому что вы не можете записать ее каким-либо другим способом, и вы ожидаете ошибку и обрабатываете ее; то все, что вы делаете, чтобы подавить неизбежное сообщение об ошибке.
1 – Вы можете отключить display_errors и включить log_errors
@ini_set('log_errors','On'); @ini_set('display_errors','Off');
2 – Вы можете использовать функции php Error и Logging по умолчанию и константы
См .: http://www.w3schools.com/php/php_ref_error.asp
3 – Вы можете реализовать свой собственный набор функций ошибок и ведения журнала с помощью файловой системы PHP