Произошла ошибка при выполнении скрипта, вы можете включить расширенный вывод ошибок в файле настроек php
Обновлено: 21.11.2024
Довольно часто я пытаюсь запустить PHP-скрипт и просто получаю пустой экран. Нет сообщения об ошибке; просто пустой экран. Причиной могла быть простая синтаксическая ошибка (неправильная скобка, отсутствие точки с запятой), сбой вызова функции или что-то еще.
Очень сложно понять, что пошло не так. В конце концов я комментирую код, везде ввожу операторы «эхо» и т. д., пытаясь сузить проблему. Но наверняка должен быть лучший способ, верно?
Есть ли способ заставить PHP выдавать полезное сообщение об ошибке, как это делает Java?
@JuannStrauss, это преуменьшение. И когда вы, наконец, видите ошибки, там написано T_PAAMAYIM_NEKUDOTAYIM. Или, может быть, "должен быть экземпляром целого числа, заданного целого числа".
Если у вас возникла ошибка синтаксического анализа, ни один из них не будет работать на многих веб-хостах, и у вас может не быть доступа к журналам ошибок. Вам нужно будет установить php на свой локальный компьютер (XAMPP в Windows и т. д.) и выполнить проверку синтаксиса командной строки php.exe -l
42 Ответы 42
Для синтаксических ошибок необходимо включить отображение ошибок в файле php.ini. По умолчанию они отключены, потому что вы не хотите, чтобы «клиент» видел сообщения об ошибках. Проверьте эту страницу в документации PHP для получения информации о двух директивах: error_reporting и display_errors. display_errors, вероятно, тот, который вы хотите изменить. Если вы не можете изменить php.ini, вы также можете добавить следующие строки в файл .htaccess:
Возможно, вы захотите использовать значение E_ALL (как указано Гамбо) для вашей версии PHP для error_reporting, чтобы получить все ошибки. больше информации
3 других элемента: (1) Вы можете проверить файл журнала ошибок, так как в нем будут все ошибки (если ведение журнала не отключено). (2) Добавление следующих двух строк поможет вам отлаживать ошибки, которые не являются синтаксическими ошибками:
(3) Другим вариантом является использование редактора, который проверяет наличие ошибок при вводе, например PhpEd. PhpEd также поставляется с отладчиком, который может предоставить более подробную информацию. (Отладчик PhpEd очень похож на xdebug и интегрируется непосредственно в редактор, так что вы используете одну программу для всего.)
Мне нравится вариант файла .htaccess. Это помогает мне выполнять отладку в области, которая не является частью общедоступного веб-сайта. Большое спасибо за этот совет!
Я бы добавил, что запись ошибок в файл (и поиск их там) — лучшее решение. Не полагайтесь на отображение ошибок на странице — они могут ее испортить, вы можете забыть включить отчеты об ошибках для рабочего сайта, и это вызовет у вас проблемы в будущем
Следующее включает все ошибки:
Также смотрите следующие ссылки
Лучше всего вносить эти изменения на уровне файла .ini. Включение отчетов об ошибках из скрипта бесполезно, так как это не поможет с синтаксическими ошибками или другими фатальными ошибками, которые убивают фазу компиляции. Сценарий уничтожается задолго до того, как он начнет выполняться и достигнет переопределения отчетов.
Если вы ищете ошибки, возникающие на этапе компиляции, проверьте журналы Apache, которые часто находятся в /var/log/apache2/error.log
Этот ответ не будет работать на php7, если включена строгая типизация, потому что вторым параметром ini_set является строка.
Следующий код должен отображать все ошибки:
Единственный способ сгенерировать пустую страницу с этим кодом — это когда у вас есть ошибка в обработчике завершения работы. Я скопировал и вставил это из своей собственной cms, не проверяя, но я уверен, что это работает.
Я получаю пустую страницу из-за этого кода. Что вы подразумеваете под «у вас ошибка в обработчике выключения» и что мне делать, чтобы решить эту проблему?
@PaoloM, он говорит об ошибке в функции ShutdownHandler выше. По сути, это временное решение вместо правильной обработки ошибок.
Это правильное решение, но будьте осторожны с разглашением информации при возникновении ошибки. (предпочитаю ведение журнала, а не эхо для пользователей)
В отлаживаемый файл можно включить следующие строки:
Это переопределяет настройки по умолчанию в php.ini, которые просто заставляют PHP сообщать об ошибках в журнал.
Это правда. В этом случае значения должны быть установлены непосредственно в ini - для чистой среды разработки это в любом случае может быть предпочтительнее.
Ошибки и предупреждения обычно появляются в файлах . \logs\php_error.log или . \logs\apache_error.log в зависимости от ваших настроек php.ini.
Кроме того, полезные ошибки часто направляются в браузер, но поскольку они недействительны в html, они не отображаются.
Поэтому "tail -f " ваши файлы журнала, и когда вы получите пустой экран, используйте параметры меню IE "view" -> "source" для просмотра необработанного вывода.
Ошибки синтаксического анализа должны быть видны в журнале ошибок Apache, независимо от того, какие настройки установлены в других местах. Если у вас нет контроля над сервером, получение журнала ошибок Apache может быть затруднено, но я предлагаю вам поговорить с вашим провайдером, и есть способы предоставить вам журнал ошибок.Помимо этого, я могу только предложить то, что есть у других — проверить свой код на предмет синтаксического анализа ошибок на локальном сервере разработки, прежде чем развертывать его в рабочей среде. Кроме того, большую помощь может оказать проверяющая среда IDE, такая как Eclipse PDT.
Возвращаясь к этому, я недавно столкнулся с проблемой переполнения стека, которая не вызывала никаких ошибок, даже в журналах, и не проявлялась как таковая, пока я не установил xdebug на сервер. Гах.
Конфигурация PHP
2 записи в php.ini определяют вывод ошибок:
В производственной среде display_errors обычно имеет значение Off (что хорошо, поскольку отображение ошибок на производственных сайтах, как правило, нежелательно!).
Однако в процессе разработки для него следует установить значение On , чтобы отображались ошибки. Проверьте!
для error_reporting (начиная с PHP 5.3) по умолчанию установлено значение E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED (это означает, что отображается все, кроме уведомлений, строгих стандартов и уведомлений об устаревании). Если вы сомневаетесь, установите для него значение E_ALL, чтобы отобразить все ошибки. Проверьте!
Воу-воу! Нет чека! Я не могу изменить свой php.ini!
Это позор. Обычно общие хосты не разрешают изменять свой файл php.ini, поэтому эта опция, к сожалению, недоступна. Но не бойтесь! У нас есть другие варианты!
Конфигурация среды выполнения
В желаемом сценарии мы можем изменить записи php.ini во время выполнения! Это означает, что он будет работать, когда запускается скрипт! Сладкий!
Эти две строки будут иметь тот же эффект, что и изменение записей php.ini, как указано выше! Потрясающе!
Я все еще получаю пустую страницу/ошибку 500!
Это означает, что скрипт даже не запустился! Обычно это происходит при синтаксической ошибке!
Из-за синтаксических ошибок сценарий даже не запускается. Он завершается ошибкой во время компиляции, а это означает, что будут использоваться значения в php.ini, которые, если вы их не изменили, могут не разрешить отображение ошибок.
Журналы ошибок
Кроме того, PHP по умолчанию регистрирует ошибки. На виртуальном хостинге он может находиться в отдельной папке или в той же папке, что и скрипт-нарушитель.
Если у вас есть доступ к php.ini, вы можете найти его в записи error_log.
Для конфигурации времени выполнения вы можете поместить эти строки в отдельный файл и включить файл php с ошибкой.
Я всегда использую этот синтаксис в самом начале php-скрипта.
Извините, но -1 за то, что я не читал другие уже опубликованные ответы. Об этом заботится в .htaccess, как уже упоминалось несколько раз.
Есть действительно полезное расширение под названием "xdebug", которое также сделает ваши отчеты намного лучше.
Действительно, это очень полезный инструмент отладки — он делает сообщения об ошибках намного более подробными, с полной трассировкой стека, дампом переменных и всем остальным.
Да. А затем используйте что-то вроде подключаемого модуля VimDebugger, чтобы просмотреть свой код и выяснить, где что-то идет не так.
Для быстрого практического устранения неполадок я обычно предлагаю здесь, в SO:
поместить в начало скрипта, который находится в процессе устранения неполадок. Это не идеально, идеальный вариант заключается в том, что вы также включаете это в php.ini и регистрируете ошибки в PHP, чтобы отлавливать ошибки синтаксиса и запуска.
Описанные здесь настройки отображают все ошибки, уведомления и предупреждения, включая строгие, независимо от версии PHP.
Что следует учитывать:
- Установите Xdebug и включите удаленную отладку в своей среде IDE.
Можно зарегистрировать ловушку, чтобы сделать видимой последнюю ошибку или предупреждение.
добавление этого кода в начало файла index.php поможет вам отладить проблемы.
Это чистое золото для тех, кто застрял на веб-хостингах, которые не показывают ошибок, но разрешают нулевой доступ к журналу
Если вы очень круты, можете попробовать:
Ошибки будут отображаться только при локальном запуске. Это также дает вам переменную test_server для использования в других местах, где это уместно.
Любые ошибки, произошедшие до запуска скрипта, не будут обнаружены, но для 99 % ошибок, которые я допускаю, это не проблема.
Если вы проводите различие между локальной и производственной средами, вам следует просто включить или отключить ошибки глобально (в файле php.ini), а не в коде, который также может быть рабочим кодом. Если вам нужно отладить рабочий веб-сайт в его производственной среде и вы хотите, чтобы вы могли только просматривать ошибки, используйте $_SERVER['REMOTE_HOST'], чтобы проверить, является ли клиент вами.
Вверху страницы выберите параметр
Важно осознавать, что синтаксическая ошибка или ошибка синтаксического анализа возникает на этапе компиляции или синтаксического анализа, а это означает, что PHP выйдет из строя еще до того, как у него появится возможность выполнить какой-либо ваш код. Поэтому, если вы изменяете конфигурацию PHP display_errors во время выполнения (это включает в себя что угодно, от использования ini_set в вашем коде до использования .htaccess, который является файлом конфигурации во время выполнения), то в игре будут только загруженные параметры конфигурации по умолчанию.
Чтобы избежать WSOD, вы должны убедиться, что в загруженном файле конфигурации параметр display_errors включен, а для параметра error_reporting задано значение -1 (это эквивалент E_ALL, поскольку он гарантирует, что все биты включены независимо от используемой версии PHP). бежим). Не задавайте постоянное значение E_ALL, потому что это значение может меняться в разных версиях PHP.
Чтобы найти загруженные файлы конфигурации, просто создайте новый файл PHP, содержащий только следующий код.
Затем укажите туда свой браузер и просмотрите загруженный файл конфигурации и проанализированные дополнительные файлы .ini, которые обычно находятся в верхней части вашего phpinfo() и будут включать абсолютный путь ко всем вашим загруженным файлам конфигурации.
Это действительно лучший способ избежать WSOD в процессе разработки. Любой, кто предлагает вам поставить ini_set('display_errors', 1); или error_reporting(E_ALL); в верхней части вашего PHP-скрипта или использование .htaccess, как вы сделали здесь, не поможет вам избежать WSOD при возникновении синтаксической или синтаксической ошибки (как в вашем случае здесь), если в вашем загруженном файле конфигурации отключена функция display_errors.< /p>
Многие люди (и стандартные установки PHP) будут использовать файл production-ini, в котором display_errors отключен по умолчанию, что обычно приводит к тому же разочарованию, которое вы испытали здесь. Поскольку PHP уже отключил его при запуске, затем обнаруживает синтаксическую ошибку или ошибку синтаксического анализа и ничего не выводит. Вы ожидаете, что ваш ini_set('display_errors',1); в верхней части вашего PHP-скрипта должно было избежать этого, но это не имеет значения, если PHP не сможет проанализировать ваш код, потому что он никогда не достигнет среды выполнения.
Установите количество секунд, в течение которых разрешен запуск скрипта. Если это достигнуто, сценарий возвращает фатальную ошибку. Ограничение по умолчанию составляет 30 секунд или, если оно существует, значение max_execution_time, определенное в php.ini .
При вызове set_time_limit() перезапускает счетчик времени ожидания с нуля. Другими словами, если тайм-аут по умолчанию равен 30 секундам, а через 25 секунд после выполнения сценария выполняется вызов, например set_time_limit(20), сценарий будет выполняться в общей сложности 45 секунд до истечения времени ожидания.
Параметры
Максимальное время выполнения в секундах. Если установлено нулевое значение, ограничение по времени не применяется.
Возвращаемые значения
Возвращает true в случае успеха или false в случае неудачи.
Примечания
Примечание:
Функция set_time_limit() и директива конфигурации max_execution_time влияют только на время выполнения самого скрипта. Любое время, затрачиваемое на действия, происходящие вне выполнения скрипта, такие как системные вызовы с использованием system() , потоковые операции, запросы к базе данных и т. д., не учитывается при определении максимального времени работы скрипта. Это неверно для Windows, где измеренное время является реальным.
См. также
Примечания, внесенные пользователями 25 примечаний
// Это гарантирует, что это всегда будет называться асинхронным
pcntl_async_signals ( 1 );
Как set_time_limit(. ), так и ini_set('max_execution_time'. ); не будет учитывать затраты времени на сон, file_get_contents, shell_exec, mysql_query и т. д., поэтому я создаю эту функцию my_background_exec() для запуска статического метода/функции в фоновом/отделенном процессе, и время истекло, убей его:
my_exec.php:
функция my_background_exec ( $function_name , $params , $str_requires , $timeout = 600 )
< $map =array( '"' =>'\"' , '$ ' => '\$' , '`' => '\`' , '\\' => '\\\\' , '!' => '\!' );
$str_requires = strtr ( $str_requires , $map );
$path_run = имя_каталога ( $_SERVER [ 'SCRIPT_FILENAME' ]);
$my_target_exec = "/usr/bin/php -r \"chdir(' < $path_run >'); < $str_requires >\\\$params=json_decode(file_get_contents('php://stdin'),true);call_user_func_array(' < $function_name>', \\\$params);\"" ;
$my_target_exec = strtr (strtr ($my_target_exec, $map), $map);
$my_background_exec = "(/usr/bin/php -r \"chdir(' < $path_run>'); < $str_requires >my_timeout_exec(\\\" < $my_target_exec >\\\", file_get_contents( 'php://stdin'), < $timeout >);\" ; //php по умолчанию использует "sh", а "sh" не поддерживает " my_timeout_exec ( $my_background_exec , json_encode ( $params ), 2 ) ;
>
функция my_timeout_exec ($cmd, $stdin = '', $timeout)
< $start = time ();
$stdout = '';
$stderr = '' ;
//file_put_contents('debug.txt', time().':cmd:'.$cmd."\n", FILE_APPEND);
//file_put_contents('debug.txt', time().':stdin:'.$stdin."\n", FILE_APPEND);
$process = proc_open ( $cmd , [[ 'pipe' , 'r' ], [ 'pipe' , 'w' ], [ 'pipe' , 'w' ]], $pipes );
if (! is_resource ( $process ))
'1' , 'stdout' => $stdout , 'stderr' => $stderr );
>
$status = proc_get_status ( $process );
posix_setpgid ($status ['pid'], $status ['pid']); //отделить pgid(идентификатор группы процессов) от родительского pgid
stream_set_blocking ( $pipes [ 0 ], 0 );
stream_set_blocking ( $pipes [ 1 ], 0 );
stream_set_blocking ( $pipes [ 2 ], 0 );
fwrite ($pipes[0], $stdin);
fclose ( $pipes [ 0 ]);
Поддержка настольного приложения Internet Explorer 11 будет прекращена 15 июня 2022 г. Те же приложения и сайты IE11, которые вы используете сегодня, можно открывать в Microsoft Edge в режиме Internet Explorer. Узнайте больше здесь.
В этой статье решена проблема, из-за которой веб-страница не может быть отображена при возникновении ошибки скрипта в Internet Explorer.
Исходная версия продукта: Internet Explorer 11, Internet Explorer 10, Internet Explorer 9
Исходный номер базы знаний: 308260
Обзор
Когда вы получаете ошибки сценария, веб-страницы могут не отображаться или работать неправильно в Internet Explorer.
При возникновении ошибок сценария в Internet Explorer вы можете получить следующие сообщения об ошибках:
Проблемы с этой веб-страницей могут помешать ее правильному отображению или функционированию. В будущем вы сможете отобразить это сообщение, дважды щелкнув значок предупреждения, отображаемый в строке состояния.
Если вы выберете Показать подробности, вы можете увидеть подробную информацию о следующих ошибках:
В строке состояния Internet Explorer также может появиться следующее предупреждающее сообщение:
Эта проблема возникает из-за того, что исходный HTML-код веб-страницы неправильно работает со сценарием на стороне клиента, например со сценарием Microsoft JScript или Microsoft Visual Basic. Эта проблема может возникнуть по одной или нескольким из следующих причин:
- В исходном HTML-коде веб-страницы возникла проблема.
- Веб-страница использует более новые технологии, которые не поддерживаются Internet Explorer.
- Веб-страница использует клиентский визуальный базовый сценарий, который устарел.
- Активные сценарии, элементы управления ActiveX или программы Java заблокированы на вашем компьютере или в сети. Internet Explorer или другую программу, например антивирусную программу или брандмауэр, можно настроить так, чтобы она блокировала сценарии Active, элементы управления ActiveX или программы Java.
- Антивирусное программное обеспечение настроено на сканирование папок временных файлов Интернета или загруженных программных файлов.
- Папки, связанные с Интернетом, на вашем компьютере повреждены.
- Драйверы вашей видеокарты повреждены или устарели.
Сценарии на стороне сервера, такие как сценарии Visual Basic в Active Server Pages (ASP), выполняются на веб-сервере. Ошибки сценария, возникающие из-за сбоев сценария на стороне сервера, не приводят к появлению сообщений об ошибках в Internet Explorer, но могут привести к тому, что веб-страница не будет отображаться или работать неправильно. Сведения об устранении неполадок в этой статье относятся к ошибкам сценариев на стороне клиента. Свяжитесь с администратором веб-сервера, если вы подозреваете, что проблема связана с серверным сценарием.
Эти методы, перечисленные в этой статье, могут помочь вам устранить ошибки сценариев, вызванные файлами или настройками на вашем компьютере. Чтобы получить краткие наглядные инструкции по устранению ошибок сценариев в Internet Explorer, посмотрите это видео:
Разрешение
Microsoft рекомендует вам обновить систему до последней доступной версии обновления Windows. Дополнительные сведения о Центре обновления Windows см. в разделе часто задаваемых вопросов.
Шаг 1. Убедитесь, что ошибки скрипта возникают на нескольких веб-страницах
Если единственным признаком этой проблемы является сообщение об ошибке, а веб-сайты работают, вы, вероятно, можете игнорировать ошибку. Кроме того, если проблема возникает на одной или двух веб-страницах, проблема может быть вызвана этими страницами. Если вы решите игнорировать ошибки, вы можете отключить отладку скриптов. Для этого установите флажок Отключить отладку скриптов (Internet Explorer) в разделе «Свойства обозревателя» > «Дополнительно» > «Настройки просмотра».
Если эта проблема возникает более чем на одном или двух сайтах, не отключайте отладку скриптов.
Шаг 2. Убедитесь, что проблема вызвана файлами или настройками на вашем компьютере
Чтобы сузить источник проблемы, используйте другую учетную запись пользователя, другой браузер или другой компьютер для просмотра веб-страниц, вызвавших ошибку скрипта.
Если ошибка сценария не возникает при просмотре веб-страницы через другую учетную запись пользователя, в другом браузере или на другом компьютере, проблема может быть вызвана файлами или настройками на вашем компьютере. В этой ситуации следуйте методам, описанным в этой статье, чтобы решить эту проблему:
После выполнения каждого метода попробуйте открыть веб-страницу, на которой вы ранее получали ошибку сценария. Если вы не получили сообщение об ошибке, проблема решена.
Способ 1. Убедитесь, что Active Scripting, ActiveX и Java не блокируются Internet Explorer
Активные сценарии, ActiveX и Java участвуют в формировании способа отображения информации на веб-странице. Если эти функции заблокированы на вашем компьютере, это может нарушить отображение веб-страницы.Вы можете сбросить настройки безопасности Internet Explorer, чтобы убедиться, что эти функции не заблокированы. Для этого выполните следующие действия:
Запустите Internet Explorer.
В меню "Инструменты" выберите "Свойства обозревателя". Если вы не видите меню «Инструменты», нажмите Alt, чтобы отобразить меню.
В диалоговом окне "Свойства обозревателя" выберите вкладку "Безопасность".
Выберите Уровень по умолчанию > ОК.
Элементы управления ActiveX и программы Java отключаются на высоком уровне безопасности в Internet Explorer.
Способ 2. Удалите все временные файлы Интернета
Каждый раз, когда вы открываете браузер для просмотра веб-страницы, ваш компьютер сохраняет локальную копию этой веб-страницы во временном файле. Если размер папки временных файлов Интернета становится слишком большим, при открытии веб-страниц могут возникнуть некоторые проблемы с отображением. Периодическая очистка папки может помочь решить проблему.
Чтобы удалить все временные файлы, связанные с Интернетом, для Internet Explorer.
Запустите Internet Explorer.
В меню "Инструменты" выберите "Свойства обозревателя". Если вы не видите меню «Инструменты», нажмите Alt, чтобы отобразить меню.
Выберите вкладку "Общие".
В разделе "История просмотров" выберите "Удалить".
В диалоговом окне "Удалить историю просмотров" установите следующие флажки, а затем выберите "Удалить":
Выберите «Закрыть», а затем нажмите «ОК», чтобы закрыть диалоговое окно «Свойства обозревателя».
Способ 3. Установите последние обновления программного обеспечения для Windows
Чтобы получать последние обновления, нажмите кнопку "Пуск" > "Параметры" > "Обновление и безопасность" > "Центр обновления Windows", а затем выберите "Проверить наличие обновлений".
Расширенная отладка
Этот раздел предназначен для более опытных пользователей компьютеров. Он включает три метода решения проблемы.
Способ 1. Убедитесь, что активные сценарии, ActiveX и Java не блокируются антивирусной программой или брандмауэром
Сценарии, элементы управления ActiveX и программы Java помогают формировать способ отображения веб-страницы. Если эти функции заблокированы, это может нарушить отображение веб-страниц.
Чтобы убедиться, что сценарии, элементы управления ActiveX и программы Java не блокируются, см. документацию по используемому брандмауэру или антивирусной программе. Затем внесите необходимые изменения.
Способ 2. Убедитесь, что ваша антивирусная программа не настроена на сканирование папок Temporary Internet Files или Downloaded Program Files
Если антивирусная программа интерпретирует сценарий как вирус и препятствует его запуску, может возникнуть ошибка сценария. Чтобы предотвратить эту проблему, убедитесь, что антивирусная программа не сканирует папку Temporary Internet Files или папку Downloaded Program Files.
Чтобы запретить программе сканирование этих папок, см. документацию используемой антивирусной программы. Затем внесите необходимые изменения. Чтобы добавить исключения в безопасность Windows в обзоре сред Windows 10, добавьте исключение в безопасность Windows.
Способ 3. Отключите плавную прокрутку
Если у вас возникли проблемы с отображением видео, функция плавной прокрутки может привести к неправильной синхронизации сценария. Это может вызвать ошибку скрипта. Чтобы отключить функцию плавной прокрутки в Internet Explorer, выполните следующие действия:
- Запустите Internet Explorer.
- В меню "Инструменты" выберите "Свойства обозревателя". Если вы не видите меню "Инструменты", нажмите клавишу Alt, чтобы отобразить меню.
- На вкладке "Дополнительно" снимите флажок "Использовать плавную прокрутку".
- Нажмите "ОК" и закройте Internet Explorer.
Если это решит проблему, проверьте, доступен ли обновленный драйвер для вашего видеоадаптера. Чтобы получить обновленный драйвер, обратитесь к производителю видеоадаптера или компьютера.
Подробнее
Процедура отключения уведомления о каждой ошибке скрипта в Internet Explorer
Запустите Internet Explorer.
В меню "Инструменты" выберите "Свойства обозревателя". Если вы не видите меню «Инструменты», нажмите Alt, чтобы отобразить меню.
На вкладке "Дополнительно" снимите флажок Отображать уведомление о каждой ошибке скрипта и нажмите кнопку ОК.
Устранение ошибок сценария при печати из Internet Explorer
Если вы попытаетесь распечатать веб-страницу в Internet Explorer, вы можете получить сообщение об ошибке сценария, похожее на следующий пример:
Как правило, устаревшие драйверы принтера могут вызывать проблемы при печати из Internet Explorer. Чтобы устранить эти проблемы, попробуйте обновить драйвер принтера до последней версии.
Чтобы решить эту проблему, выполните действия, описанные в разделе Устранение проблем с принтером в Windows 7 и Windows 8.1, чтобы проверить принтер и обновить драйвер принтера.
В некоторых случаях обновленная версия драйвера может быть недоступна через Центр обновления Windows. Возможно, вам придется посетить веб-сайт производителя, чтобы найти и загрузить последнюю версию драйвера принтера для вашего принтера.
Если вы не можете распечатать или просмотреть веб-страницу в Internet Explorer, см. следующую статью:
В этом руководстве рассматриваются основы ведения журнала в PHP, в том числе способы настройки ведения журнала, местонахождения журналов и того, как ведение журнала может помочь вам более эффективно устранять неполадки и отслеживать приложения PHP.
Всегда полезно иметь представление об основах, поэтому в этой статье рассматривается журнал ошибок, встроенный в PHP. Если вы настраиваете новое приложение или хотите улучшить существующее, мы рекомендуем вам взглянуть на библиотеки журналов PHP, если вы работаете с пользовательским стеком, или журналы PHP Framework, если вы используете такую инфраструктуру, как Laravel или Симфони.
Что касается встроенного журнала ошибок, вам следует помнить о нескольких элементах:
- Ошибки, выдаваемые самим механизмом PHP при сбое основной функции или невозможности проанализировать код.
- Пользовательские ошибки, которые вызывает ваше приложение, обычно вызванные отсутствием или неправильным вводом данных пользователем.
- Действия в вашем приложении, которые вы, возможно, захотите проанализировать позднее, например запись при обновлении учетной записи пользователя или обновлении контента в CMS
Давайте начнем с рассмотрения того, как можно настроить механизм PHP для отображения и регистрации ошибок. Эти параметры полезно проверить, если вы настраиваете новый сервер или пытаетесь выяснить, настроено ли ведение журнала на сервере, который настроил кто-то другой.
Конфигурация по умолчанию
По умолчанию конфигурация, относящаяся к ошибкам, содержится в следующих директивах в файле конфигурации php.ini. В вашей системе может быть несколько разных файлов php.ini в зависимости от того, как вы используете PHP, будь то в CLI или за веб-сервером, таким как Apache или Nginx. Здесь вы можете найти файл php.ini в распространенных дистрибутивах Linux.
Расположения файлов конфигурации по умолчанию
Операционная система | Путь | Тип |
На основе Debian (Debian, Ubuntu, Linux Mint и т. д.) | /etc/php/ 7.3/apache2/php.ini | Модуль Apache |
Redhat / Fedora / CentOS | < td width="226">/etc/php.iniВсе версии | |
OpenSUSE | /etc/php/7.3/apache2/php.ini | Модуль Apache |
Общие директивы конфигурации
Вы можете найти полный список директив на сайте документации PHP. Вот некоторые из наиболее распространенных директив, относящихся к ведению журнала.
Директива | По умолчанию | Рекомендуется | Описание |
display_errors** | 1 | 0 | Определяет, будут ли ошибки включены в вывод. |
display_startup_errors | 0 | 0 | Отображать ли ошибки последовательности запуска PHP.< /td> |
error_log *** | 0 | путь td> | Путь к файлу журнала ошибок. При запуске PHP в контейнере Docker рассмотрите возможность ведения журнала на стандартный вывод. |
error_reporting | null | E_ALL | Минимальный уровень сообщений об ошибках. |
log_errors td> | 0 | 1 | Включает регистрацию ошибок. |
log_errors_max_length | 1024 | 1024 | Максимальная длина зарегистрированных ошибок.Установите ноль, чтобы не было максимума. |
report_memleaks | 1 | 0 | Сообщает об утечках памяти, обнаруженных диспетчером памяти Zend. |
track_errors | 0 | 1 | Сохраняет последнее сообщение об ошибке в $php_errormsg. |
- ** Из соображений безопасности измените значение на 0 для веб-серверов.
- *** Если установлено значение syslog, в системный журнал будут отправляться сообщения об ошибках.
Конфигурация во время выполнения
PHP предоставляет ряд функций для чтения и изменения директив конфигурации во время выполнения. Их можно использовать в приложении для переопределения настроек в php.ini. Возможность изменять значения конфигурации полезна, когда у вас нет доступа к файлам конфигурации PHP (например, в бессерверной среде), при устранении неполадок в приложении или при выполнении определенных задач (например, задания cron, требующего дополнительной памяти). Возможно, вам придется искать вызовы ini_set() в вашем коде, если приложение ведет себя не так, как ожидалось. Например, если вы установили для display_errors значение 1 в php.ini, но по-прежнему не видите вывод ошибок, скорее всего, они где-то переопределены.
ini_get(строка)
Получает текущую настройку директивы.
ini_set(строка, смешанный)
Устанавливает директиву.
Журналы ошибок по умолчанию
Когда log_errors включен, но error_log не определен, ошибки регистрируются в журнале ошибок веб-сервера. Далее следуют расположение по умолчанию для Apache и Nginx. Обратитесь к конфигурации вашего веб-сервера, которая могла быть изменена по сравнению с настройками по умолчанию.
- Apache: /var/log/apache2/error.log
- Nginx: /var/log/nginx/error.log
Вот функции, используемые для облегчения ведения журнала ошибок приложений. В следующей таблице перечислены функции PHP, связанные с ведением журнала, а также несколько примеров. Понимание того, как ведение журналов работает в PHP, безусловно, имеет значение, но вам также следует изучить популярные библиотеки ведения журналов PHP из-за функциональности, которую они добавляют.
журнал_ошибок()
Эта функция отправляет сообщение в текущий настроенный журнал ошибок; наиболее распространенное использование:
На сервере Apache это добавит новую строку в /var/log/apache2/error.log.
Подробнее о входе в Apache можно прочитать в этом руководстве.
Вы также можете отправить сообщение в другой файл, однако это не рекомендуется, так как это может привести к путанице.
триггер_ошибка()
Вы можете использовать уровни ошибок E_USER_* в своем приложении, чтобы сообщать об ошибках различной серьезности для регистрации. Как и основные константы, существуют уровни для фатальных ошибок (E_USER_ERROR), предупреждений (E_USER_WARNING) и уведомлений (E_USER_NOTICE). В своем коде используйте функцию trigger_error() для пользовательских ошибок. Если ваш код действительно обнаружил ошибку, используйте trigger_error() с описательным сообщением, чтобы ваш обработчик ошибок знал, что что-то пошло не так, вместо того, чтобы использовать функцию die() для внезапного завершения всего.
Эта функция принимает два параметра: строку сообщения об ошибке и уровень ошибки, как показано ниже.
системный журнал()
Еще один способ протоколирования ошибок – отправить их непосредственно в систему с помощью функции syslog(). В качестве первого параметра принимает уровень ошибки (LOG_EMERG, LOG_ALERT, LOG_CRIT, LOG_ERR, LOG_WARNING, LOG_NOTICE, LOG_INFO, LOG_DEBUG); второй параметр — это фактическое сообщение об ошибке.
Пример (использование openlog() для соединения):
В приведенном выше примере новое сообщение будет записано в /var/log/syslog:
При регистрации данных вы должны убедиться, что соблюдаете осмысленное соглашение о форматировании, включая такие поля, как дата/время, имя файла, сообщение и т. д. Это позволяет лучше анализировать и искать данные. Вы также можете сделать это отдельной функцией для обработки форматирования журнала. Тот же метод используется в пакете Monolog.
Дополнительную информацию о настройке формата ведения журнала веб-сервера можно найти в нашем руководстве по ведению журналов Apache.
PHP предоставляет различные типы журналов ошибок для определения серьезности ошибок, возникших при запуске вашего приложения. Уровни ошибок указывают, что движок не может проанализировать и скомпилировать ваши операторы PHP или не может получить доступ или использовать ресурс, необходимый вашему приложению, вплоть до сообщения вам о возможной опечатке в имени переменной.
Хотя уровни ошибок являются целочисленными значениями, для каждого из них существуют предопределенные константы. Использование констант облегчит чтение и понимание вашего кода и сохранит его совместимость с будущими версиями при появлении новых уровней ошибок. Распространенные уровни ошибок включают:
- E_ERROR. Это фатальные ошибки во время выполнения, которые останавливают выполнение скрипта, например нехватка памяти или вызов несуществующей функции.
- E_WARNING. Предупреждение во время выполнения — это ошибка, которая не останавливает выполнение скрипта, но может привести к тому, что ваш код не будет работать должным образом.Например, fopen() вернет false и вызовет E_WARNING, если вы попытаетесь открыть несуществующий файл. Остальной код не сможет читать или записывать запрошенный файл.
- E_PARSE — это ошибки синтаксического анализа во время компиляции, например отсутствие скобок или точек с запятой.
- E_NOTICE. Уведомления указывают на возможные ошибки, например на использование в выражении несуществующей переменной. Это может означать, что в имени переменной есть опечатка или ему нужно присвоить какое-то значение раньше.
- E_STRICT. Эти ошибки указывают на места в вашем коде, которые могут перестать работать в будущих версиях PHP. Использование mysql_query() вызовет строгую ошибку, потому что расширение, предоставляющее эту функцию, устарело и фактически не включено в PHP 7.
Константы уровня ошибок используются функцией error_reporting(), чтобы указать, какие типы ошибок следует отображать или регистрировать. Обратите внимание, что это также можно настроить в файле INI. Вы также можете использовать побитовые операторы для настройки детализации журналов приложений.
Примечание о подавлении ошибок
Вероятно, вы сталкивались с кодом, в котором перед вызовом функции стоит символ @, который является оператором контроля ошибок. Это подавляет любые ошибки, выдаваемые этой функцией. В конце концов, это означает, что в случае сбоя функции вы не увидите никаких ошибок, связанных с ней, на экране или в ваших журналах. Это плохая практика, и ее следует избегать. Помните, что вы всегда можете настроить собственный обработчик ошибок для обнаружения ошибок.
Если вы пытаетесь исправить ошибку, но не видите никаких ошибок, найдите в своем коде вызовы функций с префиксом в один @. Вы также можете установить и включить расширение крика, которое отключит это поведение и обеспечит отчеты обо всех ошибках.
Рекомендация – установите для уровня ошибки значение E_ALL, если не требуется особый вариант использования. Уведомления и предупреждения могут указывать на то, что переменные создаются не так, как вы думали.
Сообщения журнала можно генерировать вручную, вызывая error_log(), или автоматически при появлении уведомлений, предупреждений или ошибок во время выполнения. По умолчанию журнал ошибок в PHP отключен.
Вы можете включить журнал ошибок одним из двух способов: отредактировав файл php.ini или используя ini_set. Модификация php.ini — правильный способ сделать это. Обязательно перезагрузите веб-сервер после редактирования конфигурации.
Этот параметр времени выполнения необходим только в том случае, если директива log_errors не включена в качестве общей конфигурации по определенной причине, а код вашего приложения требует этого.
Рекомендация — обязательно включите отчеты об ошибках и ведение журналов на веб-серверах и отключите отображение ошибок в ответ. Отображение ошибок в ответ на живую среду является серьезной ошибкой безопасности, и ее следует избегать. Директива display_errors упоминается в следующей конфигурации из соображений безопасности.
Журналирование действий и действий пользователей предоставляет ценный источник информации для просмотра того, какие функции используются, какие шаги предпринимают пользователи для выполнения задач, а также для отслеживания и воссоздания ошибок, с которыми они сталкиваются. Хотя вы можете записывать эту активность в локальный файл, обычно вы хотите записывать ее в существующую службу регистрации, чтобы упростить анализ и создание отчетов. Вместо того, чтобы изобретать свой собственный формат — для этого потребуется специальный анализатор — используйте JSON в качестве формата ведения журнала. JSON — это структурированный формат, который позволяет службам ведения журналов и другим приложениям легко анализировать события. Дополнительную информацию о том, как получить максимальную отдачу от ведения журнала JSON, см. в разделе 8 полезных советов, которые следует учитывать при ведении журнала в формате JSON.
Рекомендация — используйте JSON для регистрации поведения пользователей и ошибок приложений. Сделайте это с самого начала, чтобы не пришлось преобразовывать или терять старые журналы.
Массивы и объекты PHP можно преобразовать в строку JSON с помощью json_encode(). Точно так же JSON можно преобразовать в нативную конструкцию PHP с помощью json_decode(). Далее следуют несколько примеров кода, которые сначала демонстрируют функции, а затем используют их для регистрации и анализа записи.
Пример: использование функции json_encode() с ассоциативным массивом
Пример: использование функции json_decode()
Исключения — это элегантный способ обработки ошибок приложений и последующего ведения журнала. Они либо выбрасываются и перехватываются в блоке try/catch/finally, либо обрабатываются пользовательской функцией исключения.
Исключения используются, когда части логики вашего приложения не могут продолжать нормальное выполнение.
Основное исключение
В PHP есть базовый класс Exception, который по умолчанию доступен в языке. Базовый класс Exception при необходимости можно расширить.
Пример: (предполагается, что директива log_errors = 1)
Приведенный выше пример создаст следующую запись в журнале ошибок:
Пользовательское исключение
Допустим, у вас есть определенная частота ошибок определенного типа, и вы хотели бы настроить специальное исключение для их обработки.В следующем примере мы создадим пользовательское исключение с именем TooManyLoginAttemptsException для обработки слишком большого количества попыток входа в систему.
Определите собственный класс исключений:
Определите класс для генерации пользовательского исключения:
Код пытается войти в систему пользователя, перехватившего пользовательское исключение:
Если бы мы запустили завершенную программу, вывод был бы примерно таким:
Исключения SPL
В PHP есть встроенная библиотека кода, которая называется «Стандартная библиотека PHP» или SPL. В библиотеке определен ряд классов исключений, которые доступны для распространенных ошибок на уровне кода. Эти исключения внутренне расширяются из базового класса PHP Exception. Они различаются только по имени и могут быть брошены, пойманы и зарегистрированы.
Определить класс для создания исключения SPL: (BadMethodCallException)
В примере используется магический метод PHP __call() для перехвата неопределенного вызова метода.
Попытка кода использовать неопределенный метод:
$adapter = новый адаптер();
> поймать (BadMethodCallException $e)
Изменения исключений PHP 7
В PHP 7 иерархия исключений изменилась в ядре. Представлен интерфейс Throwable, и классы Exception и Error реализуют его. Это дает возможность перехватывать внутренние исключения PHP, такие как TypeError, ParseError и т. д. Вплоть до версии PHP 5 неустранимые ошибки нельзя корректно обрабатывать, поскольку они немедленно прерывают выполнение программы. Полная документация приведена здесь.
Интерфейс Throwable нельзя реализовать напрямую с помощью настраиваемых исключений, и для реализации он должен наследоваться от базового класса Exception.
Читайте также: