Php красивый вывод ошибок

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

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

И вот тут решить все эти проблемы нам поможет Whoops!

Что такое Whoops

Whoops — это небольшая библиотека/фреймворк для работы с ошибками и исключениями в PHP. Из коробки он предоставляет аккуратный и удобный интерфейс, который помогает вам вести разработку быстро.

Удобный красивый интерфейс

То, как выводит сообщение об ошибке whoops, на порядок (а то и на два) удобнее, чем нативный вывод PHP или xDebug. Интерфейс whoops позволяет быстро ориентироваться в стеке вызовов и находить нужное место в коде.

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

Whoops\Example\Exception thrown with message "Something broke!"

 где слова ‘thrown with message’ явно лишние, или, например, чем такое:

Notice: Undefined offset: 0 in D:\localhost\projects\test\test.php on line 27

в котором нужно только само сообщение ‘Undefined offset: 0’ и… да и пожалуй, всё, т. к. любезно выведенный whoops-ом наглядный кусок кода — это намного удобнее, чем название файла и номер строки. У вас наверняка этот файл открыт в данный момент и вы наверняка помните где этот кусок кода — просто визуально, а не по номеру строки.

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

Ну и плюс к этому ниже справа находится раздел «Environment & details», в котором выведены переменные окружения, информация о запросе (GET, POST, Files, Cookies), информация о php-сессии и «Server/Request Data» ($_SERVER), что часто бывает очень полезно.

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

API и фичи

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

Фичи

Вот так «нескромно» , но правдиво рассказывают о библиотеке её разработчики:

• Гибкий стековый перехват ошибок
• Не требует зависимостей (на данный момент)
• Простое API для работы с исключениями, фреймами стека вызовов и их данными
• Включает информативную страницу ошибки
• Возможность открыть указанный файл прямо в вашем IDE/редакторе
• Включает обработчики для разных форматов ответа (JSON, XML, SOAP)
• Легко расширяется и легко интегрируется в другие библиотеки и фреймворки
• Аккуратный, хорошо структурированный и протестированный код

И тут сразу глаз цепляется за такую возможность, как открывать файлы сразу в IDE. На данный момент whoops из коробки поддерживает следующие IDE/редакторы:

• Emacs
• IDEA
• MacVim
• PhpStorm (только для MacOS)
• Sublime Text 2 и возможно 3
• Textmate
• xdebug-формат
• VSCode

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

Установка

Как и любую современную библиотеку, whoops можно установить с помощью composer:

composer require filp/whoops

Но я бы рекомендовал --dev .

Подключение и настройка

В базовом варианте с подключением красивого вывода всё просто до безобразия:

$whoops = new \Whoops\Run;
$whoops->pushHandler(new \Whoops\Handler\PrettyPageHandler);
$whoops->register();

Для более детального погружения и понимания как это можно настроить под ваши нужды, разработчики предоставили набор примеров, которые вы сможете найти в папке examples/. А также подробную документацию по API.

Настройка ссылки для открытия файла

Для готовых обработчиков ссылок всё просто:

use Whoops\Handler\PrettyPageHandler;

$handler = new PrettyPageHandler;
$handler->setEditor('sublime');

Параметр editor может принимать следующие значения:

• emacs — Emacs
• idea — IDEA
• macvim — MacVim
• phpstorm — PhpStorm (MacOS)
• sublime —Sublime Text 2 and possibly 3 (на OS X вам, возможно, потребуется специальный обработчик)
• textmate — Textmate
• xdebug — xdebug (xdebug.file_link_format)
• vscode — VSCode (Opening VS Code with URLs)

Добавление обработчика ссылки для своего редактора тоже очень просто:

$handler->setEditor(function($file, $line) {
    return "whatever://open?file=$file&line=$line";
});

Подробнее можно посмотреть тут.

Интеграция с фреймворками

Whoops имеет готовые интеграции практически со всеми фреймворками:

Symfony, в Laravel 4 и Laravel 5.5+ встроен из коробки, для Laravel 5, для Silex 1 и Silex 2, для Phalcon, для CakePHP 2 и CakePHP 3, для Zend 2 и Zend 3, Yii 1, FuelPHP, Slim, Pimple.

Ну и для любого фреймворка, который поддерживает StackPHP middlewares или PSR-7 middlewares.

Если я что-то не перечислил здесь, вы можете смело открывать поиск на packagist и вы наверняка найдёте готовый пакет.

Заключение

Этот небольшой, лёгкий и удобный пакет просто, как говорится, MUST HAVE!!! Простота в установке и настройке, а также огромное удобство при работе говорят сами за себя!

Опубликовано 27.04.2023 14:00

Язык программирования PHP имеет уникальный вид отчетов об ошибках, в котором проще разобраться, чем в Python или C++. При этом у разработчиков есть возможность настроить отображение проблем в коде. В статье рассмотрим 3 способа проверить программу на сбои и отключить эту функцию.

Классификация ошибок

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

• E_ERROR — фатальные проблемы, из-за которых скрипт прекращает работу. Причиной может быть нехватка памяти, вызов несуществующего класса объектов, битая ссылка на подключаемый файл;
• E_WARNING — предупреждения об ошибке, которая не относится к фатальным, из-за чего программа продолжает работу. Однако она может выполнять программы не так, как запланировано. Распространенный вид ошибки, который чаще всего вызван неправильным аргументом при вызове функции;
• E_PARSE — компилятор не понимает, что написано в коде, т. к. разработчик допустил ошибки синтаксиса, например: незакрытые скобки, нет знаков препинания, перепутаны латинские символы и кириллица;
• E_NOTICE — мелкое нарушение во время выполнения скрипта. Возникает из-за обращения к несуществующим переменным, массивам, неопределенным константам;
• E_CORE_ERROR — фатальная ошибка обработчика, сгенерированная ядром языка программирования в момент запуска скрипта;
• E_CORE_WARNING — предупреждения о проблемах с ядром;
• E_COMPILE_ERROR — сбои, происходящие на этапе компиляции, которые приводят к остановке выполнения программы. Они генерируются скриптовым движком Zend;
• E_COMPILE_WARNING — уведомления о некритичных сбоях компилятора;
• E_DEPRECATED — предупреждение о том, что программист использует устаревшие конструкции, которые не будут работать после обновления среды разработки.

Способы вывода ошибок

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

Через .htaccess

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

php_flag display_startup_errors on

php_flag display_errors on

php_flag html_errors on

А для отключения отображения проблем разработчики используют похожие команды:

php_flag display_startup_errors off

php_flag display_errors off

php_flag html_errors off

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

Через логи PHP

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

Чаще всего программисты используют команду error_reporting. Режим вывода всех обнаруженных сбоев включается следующим образом:

error_reporting(E_ALL)

Для отключения вывода ошибок необходимо подставить 0 в скобки — error_reporting(0). Если же нужно убрать логирование только повторов ошибок, рекомендуется воспользоваться командами:

php_flag ignore_repeated_errors on

php_flag ignore_repeated_source on

Это удобный вариант для проверки файлов на ошибки, однако он работает непосредственно на устройстве разработчика. Можно сделать вывод с логированием через веб-сервер. В зависимости от платформы программисты пишут:

• для Apache — ErrorLog «/var/log/apache2/my-website-error.log»;
• для Nginx — error_log /var/log/nginx/my-website-error.log.

Если разработчик пользуется другим софтом, он может найти нужные аргументы на официальном сайте PHP.

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

Однако если программный код длинный, а настроить отображение нужно только для отдельного фрагмента, подойдет другая команда. Она выглядит следующим образом:

ini_set('display_errors', 'On')

error_reporting(E_ALL)

Чтобы отключить вывод программных сбоев, необходимо изменить команду на: ini_set(‘display_errors’, ‘Off’).

Также стоит вызвать директиву display_errors = on. Она позволит посмотреть все существующие ошибки, включая мелкие синтаксические недочеты, которые не отображаются простой функцией ini_set.

Найти актуальный INI-файл легко найти, вызвав функцию phpinfo (). Он будет помечен, как файл конфигурации — loaded configuration file.

Какой способ выбрать

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

Команда .htaccess имеет две директивы: display_startup_errors и display_errors. С их помощью можно легко настроить вывод информации о программных сбоях и синтаксических проблемах.

PHP.ini также удобен в работе и подойдет для проверки кода всего сайта. Однако не все провайдеры позволяют редактировать этот файл, что важно учитывать. Рекомендуется выбирать хостинги, которые не блокируют эту возможность.

Заключение

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

Начинающим разработчикам, которые работают в одном файле и не пользуются веб-серверами, подойдет первый метод отображения. Продвинутым программистам стоит пользоваться логами PHP, которые позволяют управлять выводом, не затрагивая другие скрипты. А администраторам серверов нужно освоить php.ini, т. к. его действие распространяется на все ресурсы, размещенные на одном веб-сервере.

На рабочем сайте так делать НЕЛЬЗЯ (это при том, что я не люблю пишущих капсом и делать категоричные заявления)

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

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

Клиенту должно быть возвращено сообщение c извинениями и рекомендациями по дальнейшим действиям. Что-то вроде такого:

Извините, произошла ошибка. В ближайшее время мы ее устраним. Вы
можете попробовать перезагрузить страницу позже. Если проблема не
будет устранена, позвоните нам +7 (555) 555-55-55 или напишите на
support@oursite.com.

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

Также если у вас серьезный сайт и есть реальная техподдержка с нормами реагирования, фраза «В ближайшее время» может быть заменена на «Не позднее …»

EDIT

Actually, I just realized the «error» you’re talking about involves an echo/print out. Here’s the problem.

You’re printing (echoing) the string error DIRECTLY TO the output buffer (which sends the HTML to the browser when you’re finished running all your code). echo() and print() sends what you are echoing/printing straight out, unless it’s in an output_buffer block (I won’t confuse you with details on that).

So, you’re managing your regular html/text output in such a way as to NOT print the page content out to the output buffer, but in this case you are using an echo, which sends the string data directly to the buffer AT THAT MOMENT.

For instance:

Your problem in a simple example

<?php

$mystr = "<html>";
$mystr .= "<body><h1>Hello World</h1></body></html>";

echo "<head></head>";

echo $mystr;

?>

Which would give me on output to the browser:

<head></head><html><body><h1>Hello World</h1></body></html>

I am storing the string data, but echoing the HEAD block before I echo the other html data.

What I need to do instead:

<?php

$mystr = "<html>";
$mystr .= "<head></head>";
$mystr .= "<body><h1>Hello World</h1></body></html>";

echo $mystr;

?>

Which would give me on output to the browser:

<html><head></head><body><h1>Hello World</h1></body></html>

I am storing the string output (your error, in this case) until I need to output it later. This is what you need to know, and accomplish in your code.

I would investigate error_reporting(0)/display_errors, error_get_last, and set_error_handler.

http://www.php.net/manual/en/function.error-reporting.php

http://www.php.net/manual/en/errorfunc.configuration.php#ini.display-errors

http://php.net/manual/en/function.error-get-last.php

http://www.php.net/manual/en/function.set-error-handler.php

So that you could stop sending all errors immediately to the output buffer (which is why it’s at the top of the page), and then capture, store and present your errors.

error_reporting(0);

set_error_handler('phpLogError');

function phpLogError() {
    $error = error_get_last();

    if ($error['type'] == 1) {
        //do your stuff    
    } 
}

function phpGetLoggedErrors() {
    // return your prettified html errors
}

Or, in other words…

php_error_handle.php

<?php

$GLOBAL['_logged_php_errors'] = array();

error_reporting(0);

set_error_handler('phpLogError');

function phpLogError() {
    global $_logged_php_errors;

    $error = error_get_last();

    if ($error['type'] == 1) {
        $_logged_php_errors[] = "<span>$error</span>";
    } 
}

function phpGetLoggedErrors() {
    global $_logged_php_errors;

    return "<ol><li>".implode('</li><li>',$_logged_php_errors)."</li></ol>";
}

?>

other.php

<?php

require_once 'php_error_handle.php';

// other stuff, pages included/required, etc...

Just make sure this require_once happens at the first line of code.