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

Page / - Изменено Alexandr Fokin в 2023/02/12 15:50 

Об обработке ошибок 
Изменено Alexandr Fokin
в 2023/02/12 15:50

Оглавление

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

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