Когда подавлять ошибки в PHP

По моему опыту, вы никогда не должны подавлять ошибки на индивидуальном уровне. В вашей производственной среде установите сообщение об ошибке в 0 и отобразите ошибки в выключенном состоянии. Если у вас есть такие индивидуальные судороги, они стреляют в ногу, когда вы возвращаетесь, чтобы исправить ошибку через 6 месяцев, забудьте о ней и не можете понять, почему ошибки не появляются, но что-то явно нарушено.

В вашем конкретном случае просто установите $ isLoggedIn в false, а затем переопределите это значение в месте, в котором вы в настоящее время его создаете (я предполагаю здесь структуру кода).

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

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

Выполнение if (@ $ var) дает идентичный результат, если (! Empty ($ var)), поэтому просто используйте это вместо этого, поскольку это более семантически правильный способ его проверки.

http://php.net/manual/en/language.operators.errorcontrol.php

Ваша переменная должна всегда существовать, по крайней мере, инициализировать ее значением false и после входа в систему установить ее в значение true. Что касается подавления, я бы рекомендовал пойти со вторым методом.

Предупреждение

В настоящее время префикс оператора ошибки «@» даже отключает отчет об ошибках для критических ошибок, которые прекратят выполнение скриптов. Между прочим, это означает, что если вы используете «@» для подавления ошибок от определенной функции, и либо она недоступна, либо была опечатана, скрипт будет умирать прямо там без указания относительно причины.

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

Теперь у нас все получилось.

Это предупреждение, а не ошибка.

Да, предупреждающие сообщения иногда могут быть PITA. Но некоторые люди любят строгую проверку переменных. Использование оператора подавления обеспечивает более целенаправленный подход, чем подавление всех сообщений E_STRICT, поэтому, хотя мне нравится поддержка PHP для разрешения использования переменных с объявлениями, это то, что я делаю (и используйте try {} catch (), где это тоже необходимо) ,

Поэтому используйте любой метод, в котором он является подходящим, но сделайте LOG эти предупреждения, когда они не будут подавлены – это то, что вам нужно исправить, даже если исправление просто добавляет подавление.

Наиболее логичным способом было бы всегда объявлять эти переменные – особенно важные, такие как $isLoggedIn – и проверить, верно ли это:

 if ($isLoggedIn) 

или только установите его, если это правда:

  if (isset($isLoggedIn) 

На мой взгляд, первый вариант лучше, и смешивание обоих не является хорошим решением!

Если я не уверен, установлена ​​ли переменная, но я хочу знать, верно ли это, тогда я пишу:

 if(!empty($var)){} 

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

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

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

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

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