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

Быстрое включение вывода ошибок в скрипте

Когда нужно срочно увидеть, что не так в одном файле, не лезьте в php.ini или .htaccess. Просто добавьте пару строк в начало скрипта — и ошибки выведутся сразу. Это работает на лету, без перезагрузки сервера. Удобно для тестов или чужого кода.

Например, если у вас undefined variable или syntax error, скрипт покажет детали: номер строки, файл и сообщение. Без этих настроек PHP может просто выдать белый экран. Такой подход не влияет на весь сайт, только на текущий скрипт и подключаемые файлы. Логично начинать с него, а потом переходить к глобальным настройкам.

Вот базовый набор команд для полного вывода:

• error_reporting(E_ALL); — включает все типы ошибок, от критических до замечаний.
• ini_set('display_errors', 1); — выводит ошибки прямо в браузер или консоль.
• ini_set('display_startup_errors', 1); — ловит ошибки на этапе запуска PHP.

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

Настройка через .htaccess и php.ini

На хостинге без root-доступа .htaccess — ваш лучший друг для глобального управления ошибками. Добавьте директивы в корневой файл, и они сработают для всего сайта. Это быстрее, чем править php.ini, который может быть недоступен.

Для включения используйте php_flag: on для display_errors и startup_errors. Отключение — off. Если хостинг блочит изменения, пишите в поддержку. В php.ini меняйте те же параметры, но после правок перезапустите Apache командой sudo apachectl -k graceful. Такой метод подходит для серверов, где вы админ.

Сравнение способов:

| Метод | Доступ | Область действия | Минусы |
|-------|--------|------------------|--------|
| .htaccess | Хостинг | Директория | Не всегда работает |
| php.ini | VPS/Сервер | Весь сервер | Требует рестарта |
| ini_set() | Любой скрипт | Локально | Только runtime |

• php_flag display_errors on — базовая директива для .htaccess.
• display_errors = On — в php.ini, с перезапуском.
• Плюс html_errors on — ошибки подсвечиваются как код, удобно читать.

Типы ошибок и error_reporting

PHP различает кучу типов ошибок: от E_ERROR (фатальные, скрипт умирает) до E_NOTICE (мелкие замечания). Функция error_reporting позволяет выбрать, что показывать. По умолчанию многие отключены, так что код работает, но с багами.

Например, E_WARNING — предупреждение о проблеме, скрипт живёт дальше. E_PARSE — синтаксис, вообще не запустится. Укажите константы через | для комбинаций: E_ALL | E_STRICT для максимума. Это помогает фокусироваться: на dev — всё, на проде — только критику в лог.

Полный список ключевых типов:

• E_ERROR — критическая, остановка.
• E_WARNING — предупреждение, код продолжается.
• E_NOTICE — замечание, возможно баг.
• E_USER_ERROR — ручная ошибка через trigger_error().
• E_DEPRECATED — устаревший код, готовьтесь к апдейту.

Используйте E_ALL для старта, потом сужайте.

Продвинутая обработка: обработчики и исключения

Стандартный вывод — для новичков. Профи пишут кастомные обработчики с set_error_handler(). Они ловят ошибки, логируют и решают: показать или спрятать. Плюс try/catch для Throwable (ошибки + исключения в PHP 7+).

Представьте: ошибка в базе — не 500, а красивое сообщение пользователю. Обработчик получает $errno, $errMsg, $file, $line — полный стек. Библиотеки вроде Whoops или Symfony Debug делают это красиво, с трассировкой. Добавьте register_shutdown_function для фатальных ошибок.

Пример простого обработчика:

• Определите функцию: function myHandler($no, $msg, $file, $line) { echo “Ошибка #$no в $file:$line: $msg”; }
• Вызовите set_error_handler(‘myHandler’);
• Для исключений: try { код } catch (Throwable $e) { лог $e->getMessage(); }

Классы ошибок в PHP 7.4+: Error, TypeError, ParseError — ловите их отдельно. Не забудьте ob_start() для буфера вывода.

Когда вывод ошибок мешает продакшену

На боевом сервере ошибки в браузер — дыра в безопасности. Они раскрывают пути файлов, версии PHP и SQL-запросы. Лучше логируйте в файл: error_log() или syslog. Отключите display_errors, оставьте только в логах.

Разница dev/prod простая: dev — экран + все типы, prod — лог + минимум. Используйте окружения: if ($_SERVER[‘SERVER_NAME’] == ‘dev.site’) { включить вывод }. Подумайте о мониторинге: Sentry или ELK для анализа логов. А трассировка через debug_backtrace() спасёт в сложных случаях.

Осталось место для нишевых тем: asserts, trigger_error для тестов и интеграция с фреймворками.