Вывод сообщений ошибок на экран

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

В этой статье я расскажу как заставить PHP выводить сообщения об ошибках на экран монитора в окне браузера. Инструкция справедлива для случая когда вы используете веб сервер Apache и если PHP для Вашего сайта подключен как модуль Apache.

Вывод ошибок на экран следует включать только во время отладки сайта. Наличие такого кода может негативно сказаться на безопасности веб-приложения.

Включение вывода ошибок PHP на экран с помощью файла .htaccess

Это очень удобный способ для отладки PHP кода. Работает практически во всех случаях. В папку со скриптом на сайте помещаем файл .htaccess со следующим содержимым:

php_flag display_errors on
php_flag display_startup_errors on
php_flag error_reporting E_ALL

где:

• display_errors — включает опцию для вывода ошибок на экран вместе с остальным кодом.
• display_startup_errors — включает опцию вывода ошибок, возникающих при запуске PHP, когда еще не работает директива display_errors.
• error_reporting — указывает, какие ошибки выводятся по уровню значимости. При значении директивы E_ALL отображаются все ошибки.

Включение вывода ошибок PHP на экран в коде файла PHP

Этот способ удобен тем, что выводом ошибок на экран вы управляете в самом скрипте PHP. Параметры, заданные с помощью функции ini_set(), имеют более высокий приоритет и перекрывают директивы php.ini и .htaccess. Разместите следующий код в начале PHP файла:

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
ini_set('error_reporting', E_ALL);

Включение вывода ошибок PHP на экран с помощью файла php.ini

Этот способ актуален когда вы являетесь администратором сервера. В файле php.ini отредактируйте следующие строки (добавьте при необходимости):

display_errors = On
display_startup_errors = On
error_reporting = E_ALL

Лучший способ вывода PHP ошибок на экран

На мой взгляд обычному пользователю удобнее всего использовать .htaccess, особенно если у вас больше чем один PHP файл. Способ №2 удобен для отладки одного php файла, чтобы не затрагивать уровень вывода ошибок для других php скриптов. Вариант с php.ini подойдет только администраторам сервера, но зато его действие распространяется на все сайты расположенные на данном сервере.

Благодарности

При написании статьи были использованы следующие источники:

1. http://drupalace.ru/lesson/vyvod-oshibok-php-na-ekran
2. https://help.sweb.ru/entry/137
3. http://ramzes.ws/blog/vkljuchit-vyvod-oshibok-php
4. http://php.net/manual/ru/function.error-reporting.php

Содержание:

• Способы вывода ошибок PHP
• Виды ошибок в файле .htaccess
• Как включить вывод ошибок через .htaccess
• Примеры практического применения
• Включение журналирования ошибок PHP в .htaccess
• Дополнительные способы вывода ошибок PHP

Ошибки в коде — неотъемлемая часть любого процесса разработки. Чтобы понять, почему не выполняется скрипт, необходимо вывести error-логи PHP на экран.

Следует помнить, что в публичной версии сайта вывод ошибок на экран должен быть отключён.

• Через файл .htaccess, отвечающий за дополнительные параметры сервера Apache.
• Непосредственно через PHP-скрипт.
• Через файл php.ini, содержащий настройки интерпретатора PHP.

Преимущества вывода ошибок в файле .htaccess

1. Широкий охват. Параметры распространяются на все элементы дочерних поддиректорий.
2. Быстрота и удобство. Обработка ошибок настраивается в несколько команд и в одном месте.

Вывод ошибок на экран лучше делать через файл .htaccess, особенно когда PHP-файлов несколько. Поэтому далее разберём этот способ подробнее.

Виды ошибок PHP в файле .htaccess

• E_ALL — все виды ошибок, кроме E_STRICT до PHP 5.4.0.
• E_ERROR — фатальные ошибки, прекращающие работу скрипта.
• E_WARNING — ошибки-предупреждения. Не являются фатальными, поэтому не вызывают прекращение работы скрипта.
• E_PARSE — ошибки разбора. Могут возникать только во время компиляции.
• E_NOTICE — уведомления о нарушении времени выполнения скрипта.
• E_CORE_ERROR — фатальная ошибка обработчика. Генерируется ядром во время запуска PHP-скрипта.
• E_CORE_WARNING — предупреждения компиляции, возникающие при запуске PHP-скрипта.
• E_COMPILE_ERROR — фатальные ошибки, возникающие на этапе компиляции.
• E_COMPILE_WARNING — предупреждение компилятора PHP-скриптов.
• E_USER_ERROR — ошибки, сгенерированные пользователями.
• E_USER_WARNING — предупреждения, сгенерированные пользователями.
• E_USER_NOTICE — уведомления, сгенерированные пользователями.

Как включить вывод ошибок через .htaccess

Файл .htaccess должен находиться в корневой директории сайта (например, «public_html»). Отредактировать его можно с помощью проводника, доступного в панели хостинга.

Примечание. Если файла .htaccess нет, то его необходимо создать.

Включить отображение ошибок PHP и настроить фильтрацию их вывода можно двумя директивами: «display_errors» и «error_reporting». Первая отвечает за состояние режима показа ошибок («On» или «Off»), а вторая задаёт глубину отображения.

Показать ошибки PHP на экране можно с помощью следующего кода:

php_flag display_errors on
php_value error_reporting -1

После сохранения изменённого файла, следует обновить страницу.

Примеры практического применения

Используя указанный код, можно быстро включить или отключить вывод ошибок, а также настроить различные конфигурации для разных режимов работы.

Следующий код скроет ошибки PHP с экрана:

# скрыть ошибки php
php_flag display_startup_errors off
php_flag display_errors off
php_flag html_errors off
php_value docref_root 0
php_value docref_ext 0

Иногда нужно фиксировать сбои, но нет возможности вывести ошибки PHP на экран  (например, сайт работает в реальном времени). Для этого можно перенаправить вывод информации в лог-файл с помощью следующего кода:

# включить ведение журнала ошибок PHP
php_flag  log_errors on
# месторасположение журнала ошибок PHP
php_value error_log /var/www/имя_пользователя/data/www/ваш_www-домен/

Чтобы обработка ошибок в .htaccess выполнялась безопасно надо обязательно защитить папку с log-файлами от внешнего доступа при помощи следующего кода:

# запретить доступ к журналу ошибок PHP
<Files PHP_errors.log>
Order allow,deny
Deny from all
Satisfy All
</Files>

Можно также настроить фильтрацию. Флаг «integer» указывает на глубину вывода данных (уровень показа). Значение «0» не выведет никаких ошибок. Комбинация «8191» запишет в log-файл сбои всех уровней.

# общая директива для фильтрации ошибок php
php_value error_reporting integer

Чтобы текст ошибок не обрезался, можно установить максимальный размер на строку:

# общая директива для установки максимального размера строки
log_errors_max_len integer

Выключение записи повторяющихся ошибок сократит объём поступающих данных и улучшит восприятие информации:

# отключить запись повторяющихся ошибок
php_flag ignore_repeated_errors on
php_flag ignore_repeated_source on

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

# обработка ошибок PHP для публичного ресурса
php_flag display_startup_errors off
php_flag display_errors off
php_flag html_errors off
php_flag log_errors on
php_flag ignore_repeated_errors off
php_flag ignore_repeated_source off
php_flag report_memleaks on
php_flag track_errors on
php_value docref_root 0
php_value docref_ext 0
php_value error_reporting -1
php_value log_errors_max_len 0

<Files /home/path/public_html/domain/PHP_errors.log>
Order allow,deny
Deny from all
Satisfy All
</Files>

Во время разработки или отладки файл .htaccess должен содержать следующий код:

# Обработка ошибок PHP во время разработки
php_flag display_startup_errors on
php_flag display_errors on
php_flag html_errors on
php_flag log_errors on
php_flag ignore_repeated_errors off
php_flag ignore_repeated_source off
php_flag report_memleaks on
php_flag track_errors on
php_value docref_root 0
php_value docref_ext 0
php_value error_log /home/path/public_html/domain/PHP_errors.log
# [see footnote 3] # php_value error_reporting 999999999
php_value error_reporting -1
php_value log_errors_max_len 0

<Files /home/path/public_html/domain/PHP_errors.log>
Order allow,deny
Deny from all
Satisfy All
</Files>

Включение журналирования ошибок PHP в .htaccess

Когда отображение ошибок на странице выключено, необходимо запустить их журналирование следующим кодом:

# включение записи PHP ошибок
php_flag log_errors onphp_value error_log /home/path/public_html/domain/PHP_errors.log

Примечание. Вместо «/home/path/public_html/domain/PHP_errors.log» нужно подставить собственный путь до директории, в которой будет вестись журнал ошибок.

Чтобы запретить доступ к журналу извне, нужно добавить следующий код:

# предотвращаем доступ к логу PHP ошибок
<Files PHP_errors.log>
Order allow,deny
Deny from all
Satisfy All
</Files>

Дополнительные способы вывода ошибок PHP

Можно добавить оператор «@», чтобы запретить показ ошибок в конкретной инструкции PHP:

$value = @$var[$key];

Вывод ошибок в PHP-скрипте

Чтобы выводить все ошибки, нужно в начале скрипта прописать:

error_reporting(-1);

Если необходимо отображать ошибки PHP только из определённого места скрипта, то можно использовать следующий код:

ini_set('display_errors', 'On'); // сообщения с ошибками будут показываться
error_reporting(E_ALL); // E_ALL - отображаем ВСЕ ошибки
$value = $var[$key]; // пример ошибки
ini_set('display_errors', 'Off'); // теперь сообщений НЕ будет

Примечание. Если заменить значения «On» и «Off» в первой и последней строках на противоположные, то на конкретном участке кода ошибки выводиться не будут.

Через файл php.ini

Включить или выключить показ ошибок на всём сайте/хостинге также можно с помощью файла «php.ini», в котором нужно изменить два следующих параметра:

error_reporting = E_ALL
display_errors On

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

Время на прочтение
4 мин

Количество просмотров 18K

Приветствую!

В статье посвященной моему профайлеру для Entity Framework-a, я вкратце описал примененную мной форму для сообщения пользователю об исключительной ошибке в приложении. После оценки количества скачиваний примера кода, было решено выделить этот пример в отдельный проект, а также добавить поддержку WPF приложений.
Исходники библиотеки вместе с примерами опубликованы на CodePlex под свободной лицензией MIT: https://uiexceptionhandler.codeplex.com/

Подробности под катом.

Введение

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

Что получилось

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

При клике по кнопке «Error detail information» выводиться дополнительная информация об ошибке:

Кнопка Debug позволяет подключить отладчик Visual Studio.
Кнопка «Send to Developer» отправляет письмо на почту разработчику. В случае ошибки отправки сообщения, пользователю будет предложено самому отправить лог файл разработчику на почту.
Отправленное разработчику сообщение придет в таком виде:

Использование

1. Забрать последнюю версию кода https://uiexceptionhandler.codeplex.com/SourceControl/latest
2. Собрать в Release mode.
3. Из папки «UIExceptionHandlerLibsDeploy» подключить в проект библиотеку UIExceptionHandlerWinForms.dll в случае WinForms приложения и UIExceptionHandlerWPF.dll в случае WPF приложения.
4. Инициализировать путем вызова статического метода с рядом параметров:

UIException.Start(
   string serverSmtp, 
   int portSmtp, 
   string passwdSmtp, 
   string userSmtp, 
   string programmerEmail,
   string fromEmail, 
   string subject
)

Как это работает

Статический метод UIException.Start подписывает метод HandleError на событие AppDomain.CurrentDomain.UnhandledException:

AppDomain.CurrentDomain.UnhandledException += (sender, e) => HandleError((Exception)e.ExceptionObject);

Метод HandleError:

private static void HandleError(Exception exception)
{
    try
    {
        // запускаем обработчик формы и передаем ему ссылку на форму наследованную от интерфейса IErrorHandlerForm
        new ErrorHandlerController(exception, new ErrorHandlerForm()).Run();
    }
    catch (Exception e)
    {
        // сохраняем ошибку в лог файл
        LogHelper.Logger.Error(e);
        // в случае ошибки обработки выводим сообщение с просьбой отправить лог файл разработчику на почту
       MessageBox.Show("Error processing exception. Please send log file " + LogHelper.ExceptionLogFileName + " to developer: " + Settings.ProgrammerEmail + " rn Exception:" + e);
        // спрашиваем нужно ли подключить отладчик
        if (MessageBox.Show("Attach debugger? n Only for developer!!!", "Debugging...", MessageBoxButton.YesNo, MessageBoxImage.Question) == MessageBoxResult.Yes)
        {
            Debugger.Launch();
            throw;
        }
    }
    finally
    {
        // обязательно завершаем приложение чтобы windows не вывела стандартное сообщение об ошибке
        Environment.Exit(1);
    }
}

Интерфейс IErrorHandlerForm:

public interface IErrorHandlerForm
{
    event Action OnSendButtonClick;
    event Action OnShowErrorLinkClick;
    event Action OnLogFileLinkClick;
    event Action OnDebugButtonClick;

    // меняет высоту формы
    void SetHeight(int height);
    // задает подробное сообщение об ошибке
    string ExceptionInfoText { get; set; }
    // получает текст из поля дополнительной информации введенной пользователем
    string ExceptionDetailText { get; set; }
    // email пользователя для ответа
    string ReplyEmail { get; }
    void ShowExceptionInfoTextBox(bool isShow);
    // выводит информационное сообщение
    void ShowInfoMessageBox( string text, string caption);
    // выводит диалоговое сообщение
    bool ShowQuestionDialog( string text, string caption);
    // показывает окно в режиме диалога! необходимо чтобы приложение дожидалось закрытия окна и завершилось в finaly
    void ShowViewDialog();
    void UpdateContactEmail(string contactEmail);
}

В качестве библиотеки для логгирования используется NLog. Для того чтобы избежать появления лишних xml файлов, вся конфигурация Nlog-а делается в коде:

private static void ConfigureNlog()
{
    var config = new LoggingConfiguration();

    var fileTarget = new FileTarget();
    config.AddTarget("file", fileTarget);

    fileTarget.Layout = @"${longdate} ${message}";
    fileTarget.FileName = "${basedir}/" + ExceptionLogFileName;

    var rule2 = new LoggingRule("*", LogLevel.Trace, fileTarget);
    config.LoggingRules.Add(rule2);

    LogManager.Configuration = config;
}

Чтобы добиться максимальной простой интеграции в проект, я решил все используемые сборки объединить в одну библиотеку. Делается это при помощи приложения ILMerge, путем добавления скрипта в post-build событие:

if $(ConfigurationName) == Release (
"$(SolutionDir)ILMergeILMerge.exe" /out:"$(SolutionDir)Deploy$(TargetFileName)" "$(TargetDir)*.dll" /target:dll /targetplatform:v4,C:WindowsMicrosoft.NETFramework64v4.0.30319 /wildcards
)

Послесловие

Данное решение было написано для достаточно крупного проекта, применяется уже более 2-х лет, значительно улучшив процесс исправления ошибок, поскольку о каждом падении приложения узнаешь моментально, без дополнительной нотификации от пользователя.

Надеюсь это все будет кому-то полезно!
Всем спасибо за внимание!

It depends on the app, and what the app will be able to do once it has met this
error.

The two methods that Google suggests in the Material Design Guide to deal with these types of messages are:

Dialogs (in this case the Alert Dialog):

and Snackbars:

To use your example: Some data is requested from a remote server, but because of some error or exception, the fetch fails and no data is returned.

At this point, the type of error message would depend on how the app will function from that point on, without that data. If the app will perform as it is, meaning the fetch was something akin to a background update, the appropriate thing to show would be a Snackbar. Why?

From the Guide:

Snackbars provide lightweight feedback about an operation by showing a brief message at the bottom of the screen. Snackbars can contain an action.

Lightweight is really the reason here. If the app will function without that background data fetch, you should not block the UI with a message. Just let the user know things didn’t work out the way they should so that he can do something about it if he cares.

Here is an example taken from the guide:

For code: the Developer Docs on Snackbars

Never use a Toast. A Toast is too small, too brief and can go by unnoticed. Use a Snackbar.

But, in the scenario where your app will not function, or will show nothing but a blank screen without that data, the correct thing to do would be to show an Alert Dialog.

No one wants to see nothing but a blank screen, and if you can’t populate it with data, you need to give the user a screen from which they can perform alternate functions, even if that is to quit the app.

From the Guide on Alerts:

Alerts inform the user about a situation or action that requires their
confirmation or acknowledgement before proceeding. They differ
slightly in appearance based upon the severity and impact of the
message conveyed.

Alerts are interruptive, urgent, and prevent users from proceeding
until they make a decision.

AND

Disambiguation from Snackbars: In contrast to Alerts, Snackbars
present optional but important information or actions and usually
appear after an action. For example, use an alert to confirm
discarding a draft. Use a snackbar to present an undo action, because
the action is optional and the user can continue with their primary
task without taking action.

So if the app won’t function without that data, go with an Alert Dialog.