Про разработку приложений - Об обработке ошибок

Page / - Изменено Alexandr Fokin в 2024/02/11 14:16

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

Изменено Alexandr Fokin

в 2024/02/11 14:16

Оглавление

1	Введение типов ошибок.	Наличие регламента типов ошибок. Как минимум обычно можно выделить - технические ошибки и ошибки валидации входных данных (а также ошибки валидации недопустимых действий). В целом модель типов ошибок может быть более сложной. Это также позволит реализовать различную логику в зависимости от типа ошибки. Дополнительно: спорный вопрос использования механизма Exception для передачи ошибок валидации входных данных.
2	Политика обработки ошибок.	При разработке приложение желательно определить политики того, как и какие ошибки мы будем передавать и перехватывать. На каком (их) уровне будет вестись обработка и принятие решений о поведении в случае ошибки.
3	Реагирование на ошибки в рамках жизненного цикла запроса / работы.	Также важно понимать как ошибки влияю на жизненный цикл обработки запроса в нашем приложении. Какие ошибки являются критичными, а какие говорят о необходимости выполнить альтернативное или повторное действие.
4	Логирование ошибок	Не должно быть ситуации, когда данные о технических ошибках просто теряются, не попав в лог. За исключением того, если определен перечень допустимых ошибок (наличие обоснования). Дополнительный вопрос: Достаточно ли хранимой и логируемой информации для понимания причины ошибки, воспроизведения ее на тестовом окружении?
5	Примеры и вопросы	У нас есть Web Api, обрабатывающее входные запросы. Учтены ли в контракте API ситуации, когда запрос завершается ошибкой (причем также могут допускаться разные типы), отражено ли это в формате ответа. (Ошибка валидации входного запроса (с указанием места ошибки), внутренняя техническая ошибка сервиса, перегрузка сервиса, невозможность обработать запроса из-за недоступность необходимых сервисов). Исходя из требований и ситуации: Насколько информативным должен быть текст ответа API в случае ошибки валидации входных данных. Проверяются ли входные данные целиком или же обработка прекращается при нахождении первого недопустимого элемента? У нас есть входная очередь и воркер, выполняющий чтение и обработку. Существуют ли какие либо ошибки, возникновение которых должно приводить к тому, что мы перестаем извлекать новые сообщения, останавливая обработку (например до наступления какого-то события), или же воркер в любом случае должен переходить к обработке следующего сообщения? Сохранение информации о проблемном сообщении (сообщение привело к появлению ошибки). В некоторых случаях может возникнуть вопрос необходимости периодической проверки доступности других сервисов или даже БД. И в случае недоступности менять поведение или останавливать обработку. В некоторых случаях возможно понадобиться учесть ситуацию, когда запрос к внешнему сервису завершен успешно, но при попытке сохранения агрегата возникает ошибка. Должно ли это приводить к каким либо последствиям (Фиксация информации о проблеме, блокировка агрегата до дальнейшего выяснения)
Техническая	Exception или некая явная ошибка, преостановившая или отменившая операцию.
Бизнес ошибки	Ситуация, когда в рамках обработки действия или процесса все было выполнено успешно. Но с точки зрения бизнеса, что-то произошло некорректно. Неверное принятые решения Т.е. можно сказать, что система принятия решений (условий) не учитывала такой вариант или сработала неучтенным образом. Также вопрос на каких данных основывалась решения делая каждый выбор (условие). Некорректный расчет Ошибка в логике расчета или же модификация данных (отсутствие необходимых блокировок).

Логи, трассировка, мониторинг

Open Telemetry