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

Редактировал(а) Alexandr Fokin 2024/02/11 14:43

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

Техническая | Exception или некая явная ошибка, преостановившая или отменившая операцию.
Бизнес ошибки | Ситуация, когда в рамках обработки действия или процесса все было выполнено успешно. Но с точки зрения бизнеса, что-то произошло некорректно.
Неверное принятые решения | Т.е. можно сказать, что система принятия решений (условий) не учитывала такой вариант или сработала неучтенным образом. Также вопрос на каких данных основывалась решения делая каждый выбор (условие).
Некорректный расчет | Ошибка в логике расчета или же модификация данных (отсутствие необходимых блокировок).

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

Open Telemetry

Создал(а) Alexandr Fokin 2021/10/16 12:13

- Комментарии (0)
- Вложения (0)
- История
- Информация

## Приложения