Поэтому я работаю над очисткой ужасной базы кода, и я медленно перехожу к полной отчетности об ошибках.
Это сложный процесс, с сотнями замечаний по следующим направлениям:
Notice: Undefined index: incoming in /path/to/code/somescript.php on line 18 из-за использования переменных, предполагающих неопределенные переменные, просто обрабатывается как false, например:
if($_SESSION['incoming']){ // do something }
Цель состоит в том, чтобы знать, когда введена некорректированная неопределенная переменная, возможность использовать строгую проверку ошибок / уведомлений в качестве первого этапа процесса рефакторинга, который, в конечном счете, включает переписывание пятен кода, которые полагаются на стандартный ввод таким образом. Есть два способа заменить переменную, которая может или не может быть определена способом, который подавляет уведомления, если он еще не определен.
Достаточно просто заменить экземпляры переменной, такие как $_REQUEST['incoming'] , которые ищут только истинные значения с помощью
@$_REQUEST['incoming'].
Весьма грязно заменить экземпляры переменной, такие как $_REQUEST['incoming'] с помощью «стандартного» теста, который
(isset($_REQUEST['incoming'])? $_REQUEST['incoming'] : null)
И вы добавляете тройную / встроенную строку, если это проблематично, потому что вы можете на самом деле вложить парны по-разному в сложный код и полностью изменить поведение.
Итак, … … есть ли неприемлемый аспект использования @ подавления ошибки @ по сравнению с использованием (isset($something)? $something : null) ?
Изменить: чтобы быть как можно более ясным, я не сравниваю «переписывание кода, чтобы быть хорошим», на «@», это этап позже в этом процессе из-за дополнительной сложности реального рефакторинга. Я только сравниваю два способа (могут быть и другие), которые я знаю, чтобы заменить $ undefined_variable версией, отличной от уведомлений.
Другой вариант, который, как представляется, хорошо работает с хромым кодом, который использует «суперглобальные элементы» повсюду, заключается в том, чтобы обернуть глобальные объекты выделенными объектами массива с более или менее разумным [] поведением:
class _myArray implements ArrayAccess, Countable, IteratorAggregate { function __construct($a) { $this->a = $a; } // do your SPL homework here: offsetExists, offsetSet etc function offsetGet($k) { return isset($this->a[$k]) ? $this->a[$k] : null; // and maybe log it or whatever } }
а потом
$_REQUEST = new _myArray($_REQUEST);
Таким образом, вы получаете контроль над «$ REQUEST» и друзьями и можете наблюдать за тем, как их использует остальная часть кода.
Вы должны решить самостоятельно, если вы оцениваете использование @ приемлемым или нет. Это трудно оценить у третьей стороны, так как для этого нужно знать код.
Тем не менее, похоже, что вы не хотите, чтобы подавление ошибок предоставляло код более доступным для вас в качестве программиста, которому необходимо работать с ним.
Вы можете создать его спецификацию при повторной факторизации используемой кодовой базы, а затем применить ее к базе кода.
Это ваше решение, используйте язык как инструмент.
Вы также можете отключить оператор подавления ошибок, используя собственную функцию обратного вызова для ошибок и предупреждений или используя расширение крика или настройку xdebug.scream .
Вы ответили на вопрос о себе. Он подавляет ошибку, не отлаживает ее.
По-моему, вы должны использовать метод isset() для правильной проверки ваших переменных.
Подавление ошибки не заставляет ее уходить, она просто перестает отображать ее, потому что она по сути говорит «set error_reporting(0) для этой строки», и если я правильно ее помню, это будет медленнее, чем проверка isset() .
И если вам не нравится тернарный оператор, тогда вы должны использовать оператор full if else. Это может сделать ваш код длиннее, но это более читаемо.
Я бы никогда не подавил ошибки на сервере разработки, но я, естественно, подавил бы ошибки на реальном сервере. Если вы работаете на реальном сервере, вы не должны. Это означает, что символ @ всегда неприемлем. Нет причин подавлять ошибку в развитии. Вы должны увидеть все ошибки, включая уведомления.
@ также немного замедляет работу, но я не уверен, что isset() работает быстрее или медленнее.
Если вам больно писать isset() столько раз, я бы просто написал такую функцию, как
function request($arg, $default = null) { return isset($_REQUEST[$arg]) ? trim($_REQUEST[$arg]) : $default; }
И просто используйте request('var') .
Большинство так называемых «программистов PHP» не понимают всей идеи назначения переменных вообще.
Просто из-за отсутствия какого-либо программирования образования или фона.
Ну, это не имеет большого значения с обычным сценарием php, закодированным со значительными усилиями и состоящим из некоторых спагетти HTML / Mysql и очень немногих переменных.
Другое дело – несколько больший код, когда писать будет относительно легко, но отладка вызывает кошмар. И вы научитесь ценить КАЖДОЕ кровавое сообщение об ошибке, когда вы понимаете, что сообщения об ошибках – ваши ДРУЗЬЯ, а не какие-то раздражающие и тревожные вещи, которые лучше завязаны.
Итак, при таком понимании вы научитесь оставлять в своем коде намеренные ошибки.
И определите все ваши переменные.
И, таким образом, создавайте сообщения об ошибках своим друзьям, сообщая вам, что что-то пошло не так, приложив усилия, чтобы выследить некоторую ошибку жесткого определения, вызванную неинициализированной переменной.
Другим смешным следствием отсутствия образования является то, что 9 из 10 «программистов PHP» не могут отличить подавление ошибок от выключения отображения ошибок и использовать вместо них прежний.
Я на самом деле обнаружил еще одно предостережение @ за пределами упомянутых здесь, что мне нужно будет рассмотреть, что связано с тем, что при работе с функциями или вызовом метода объекта @ может предотвратить ошибку даже при ошибке, убивающей скрипт, как здесь:
http://us3.php.net/manual/en/language.operators.errorcontrol.php
Что является довольно веским аргументом в пользу того, чего следует избегать в редкой ситуации, когда попытка подавить уведомление переменной подавила функцию неопределенной ошибки (и, возможно, этот потенциал, чтобы перекинуться на более серьезные ошибки, является еще одной невокализованной причиной, по которой людям не нравится @? ).