Использование расширенной отладки. Часть 8. Перехват ошибок

+13
2.19K
В стандартной версии движка пока перехватываются и обрабатываются только ошибки при обращении к базе данных. Ошибки PHP и предупреждения (в случае соответствующих настроек на сервере) не выводятся, а тихонько ложатся в лог веб-сервера. «Расширенная отладка» предоставляет несколько больше возможностей при обработке ошибок, которые будут полезны и разработчикам, и вебмастерам.

Иллюстрация


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

Иллюстрация

Основные возможности

• Перехватывает всё, от предупреждений до критических ошибок.
• Выводит трассировку места возникновения ошибки заданной глубины.
• Опционально выводит в лог контекст ошибки.
• Есть возможность выводить стандартные сообщения об ошибках в случае, когда перехватить и обработать их «Отладкой» нет возможности.
• Может уведомлять админа о критических ошибках на e-mail, а также личным сообщением или уведомлением на сайте.
• При критических ошибках возвращает ответ сервера "Status: 500 Internal Server Error".
• При критических ошибках позволяет выдать на страницу пользователя «человеческое» сообщение, задаваемое в Админке, вместо стандартного пугающего «Ошибка 500 ...». Например: «На сайте произошла ошибка. Администраторы уже получили уведомление и работают над её устранением. Спасибо за понимание.».

Уровень перехвата ошибок PHP

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

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

Контекст ошибок

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

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

Стандартный вывод ошибок

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

Критические ошибки

При критических ошибках, то есть таких, когда страница вообще не может быть создана, сервером в браузер обычно возвращается ошибка «500 Internal Server Error» («внутренняя ошибка сервера»). Во-первых, это серьёзные ошибки, которые на отлаженном сайте вообще происходить не должны. Но если всё же такое случилось, то хотелось бы об этом узнать. Во-вторых, сообщение «Ошибка 500 …» никак не успокаивает пользователей сайта.

Для уведомления админа о критической ошибке в «Отладке» предусмотрены три возможности:
— на электронную почту, заданную в Админке;
— личным сообщением на сайте указанному в Админке пользователю;
— уведомлением на сайте этого пользователя.

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

Ещё раз уточняю: Уведомления будут делаться только при критических ошибках. При обычных ошибках и предупреждениях уведомлений не будет.

А если поставить галку «При критической ошибке показывать пользователям следующее сообщение вместо ошибочной страницы» и вписать текст сообщения, то оно сохранится в настройках «Отладки» и будет показано пользователям вместо стандартного сообщения «500 Internal Server Error».

Админу в любом случае при критической ошибке на страницу будет выведена информация об ошибке, а также вся накопленная к этому времени информация отладки: статистика работы скрипта, все собранные логи с трассировками и разрешёнными опциями. Но, естественно, без цветового оформления, так как css-файл при таких ошибках не подключается. Это всё-таки гораздо лучше, чем стандартная короткая строка PHP про ошибку. Такая информация может понадобиться при отладке в особо трудных случаях, когда ошибки вроде быть не должно, а она происходит. Тогда можно перед строкой с ошибкой поставить точку отладки с выводом нужных переменных и посмотреть состояние скрипта. Выяснить причину ошибки будет намного легче.

Ошибки базы данных

В стандартной версии движка есть встроенная обработка ошибок при запросах к БД. Причём довольно жёсткая – происходит остановка скрипта и вывод информации об ошибке на чистой странице для всех запросов, кроме помеченных разработчиками как «тихие» (в функцию query() передаётся параметр $quiet=true).

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

При возникновении ошибок или предупреждений при выполнении «тихих» запросов к БД, информация о количестве ошибок и предупреждений выводится красным шрифтом на жёлтом фоне в основной таблице отладки в блоке «SQL queries». Подсчёт ошибок производится независимо от разрешения вывода SQL-запросов в лог. Так что даже если лог запросов отключён, вы всё равно увидите наличие ошибочных запросов в основной таблице. Чтобы посмотреть запросы, нужно включить вывод запросов в лог галкой «Показывать коннекты и запросы к БД». У проблемных запросов информация об ошибках также будет выделена красным шрифтом на жёлтом фоне. Стили оформления ошибок и предупреждений настраиваются в css-файле «Отладки».

Таким образом, «Расширенная отладка» дополняет стандартный перехват ошибок БД и будет полезна разработчикам, позволяя увидеть скрытые нюансы.
0
Alexprofi Alexprofi 6 лет назад #
Вы неутомимый! +
+2
WebMan WebMan 6 лет назад #
laugh Утомился. Пойду посплю.

Еще от автора

Хуки-хухуки: Исключаем неактивных пользователей из списков
Как иногда начинают свой монолог неопытные стендаперы: «У всех в жизни было такое …
«Расширенная отладка» для InstantCMS 2.14.1 (v.14.1.2) – большое обновление для разработчиков
Новые возможности и удобства, облегчающие разработчикам отладку компонентов и шаблонов.
Использование расширенной отладки. Часть 11. Анализ ошибок 403/404 и редиректов
Одной из неудобных задач при отладке для меня является поиск причины ошибки 403/404.
Используя этот сайт, вы соглашаетесь с тем, что мы используем файлы cookie.