Обработка ошибок

[toc]

Относительные классы

App

DuckPhp\Core\ExceptionManager Класс управления ошибками

Обработка ошибки 404

    'error_404' => null,

Шаблон представления/замыкание 'skip_404' => false, Пропустить обработку ошибки

Событие On404

Общие методы обработки ошибок

Относительные опции

'error_500' => null,          // '_sys/error-500',

Шаблон представления/замыкание

    'exception_reporter' => null,
    
    'exception_for_project' => null,

Далее следуют продвинутые опции.

'skip_exception_check' => false, В процессе выполнения пропускается проверка ошибок и выбрасывается вверх 'handle_all_dev_error' => true,

Управление отладочными ошибками

'handle_all_exception' => true, Управление всеми типами ошибок

Базовая обработка ошибок

По умолчанию при возникновении ошибки вызывается шаблон представления, указанный в опции error_500. Если значение является замыканием, то вызывается это замыкание вместо отображения.

Обработка ошибок контроллером

SimpleExceptionTrait.php -> ThrowOnTrait Статический метод ThrowOn ExceptionReporterTrait Используется для управления ошибками

Helper::assignExceptionHandler($classes, $callback = null); Helper::assignExceptionHandler([$class=>$callback]);

Для конкретного типа ошибки можно установить обратный вызов, который будет вызван при возникновении ошибки $callback($exception); этот метод называется assign и имеет два способа вызова.

Helper::setMultiExceptionHandler(array $classes, $callback) Чтобы удобнее было обрабатывать несколько типов ошибок одновременно, был добавлен такой способ обратного вызова, где $classes — массив названий классов ошибок. Helper::setDefaultExceptionHandler($callback)

Для всех остальных типов ошибок используется `$callback($exception);`

Общие правила обработки ошибок

Модели не должны выбрасывать ошибки.

Бизнес-логика должна выбрасывать свои собственные ошибки с помощью одноимённого класса ошибки. Например, если есть бизнес-класс SessionBusiness, то должен существовать класс ошибки SessionException. Проблемы с этими ошибками решаются вызывающим кодом.

Рекомендовано, чтобы эти классы ошибок наследовали базовый класс BaseException и реализовывали метод display($ex), что позволяет выводить информацию об ошибке при её возникновении.

Продвинутые методы обработки ошибок

'handle_all_dev_error' => true,
'handle_all_exception' => true, // опции используются для управления системными ошибками.

ExceptionReporterTrait

'skip_exception_check' => false, 

При активации во время выполнения пропускается проверка ошибок и выбрасывается вверх. Если вы не планируете самостоятельно управлять ошибками, то рекомендуется использовать эту опцию. При управлении ошибками, откройте эту опцию и выбросьте $ex; тогда ошибки будут управляться верхним уровнем.```markdown 'default_exception_do_log' => true, 'default_exception_self_display' => true,

Если метод C::setDefaultExceptionHandler не был вызван, то исключение будет обработано методом App::onDefaultException. Вы можете переопределить метод App::_onDefaultException для реализации своего управления исключениями, например, добавлением логирования.

Один из обязательных компонентов проекта DuckPhp — это _trait_ SimpleThrowTrait.

Этот _trait_ предоставляет следующий статический метод:

* `public static function throwOn($flag, $message, $code)`

Метод используется для выброса текущего типа исключения, если условие `$flag` истинно.

В PHP есть функция `assert`, которая противоположна по своей логике методу `throwOn`. Метод `throwOn` более прямолинейный в использовании.


## Примечание для основного разработчика
Обработка исключений в DuckPhp с точки зрения пользователя не требует особых действий,
но её реализация действительно сложна.

Существуют несколько случаев:
1. Ошибки до того как `init()` берёт контроль над ошибками.
2. Ошибки после того как `init()` берёт контроль над ошибками.

3. Ошибки во время выполнения `run()`, которые могут быть разделены на:
   - Ошибки при выполнении консольной команды.
   - Ошибки при выполнении других подприложений `run()`.
   - Обработка ошибок при переходе между различными фазами работы подприложений -> отметка проблем во время выполнения, таких как начальный запуск объекта (`ob_start`), который не был завершен слиянием.

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