Исходный код вики Об обработке ошибок
Версия 11.7 от Alexandr Fokin на 2023/02/03 13:28
Последние авторы
| author | version | line-number | content |
|---|---|---|---|
| 1 | |1|(% style="width:256px" %)Введение типов ошибок.|(% style="width:1208px" %)((( | ||
| 2 | Наличие регламента типов ошибок. | ||
| 3 | Как минимум обычно можно выделить - технические ошибки и ошибки валидации входных данных (а также ошибки валидации недопустимых действий). | ||
| 4 | В целом модель типов ошибок может быть более сложной. | ||
| 5 | |||
| 6 | Это также позволит реализовать различную логику в зависимости от типа ошибки. | ||
| 7 | |||
| 8 | Дополнительно: спорный вопрос использования механизма [[Exception>>doc:Разработка.NET.C#.Исключения | Exception .WebHome]] для передачи ошибок валидации входных данных. | ||
| 9 | ))) | ||
| 10 | |2|(% style="width:256px" %)Политика обработки ошибок.|(% style="width:1208px" %)При разработке приложение желательно определить политики того, как и какие ошибки мы будем передавать и перехватывать. | ||
| 11 | На каком (их) уровне будет вестись обработка и принятие решений о поведении в случае ошибки. | ||
| 12 | |3|(% style="width:256px" %)Реагирование на ошибки в рамках жизненного цикла запроса / работы.|(% style="width:1208px" %)Также важно понимать как ошибки влияю на жизненный цикл обработки запроса в нашем приложении. Какие ошибки являются критичными, а какие говорят о необходимости выполнить альтернативное или повторное действие. | ||
| 13 | |4|(% style="width:256px" %)Логирование ошибок|(% style="width:1208px" %)((( | ||
| 14 | Не должно быть ситуации, когда данные о технических ошибках просто теряются, не попав в лог. | ||
| 15 | За исключением того, если определен перечень допустимых ошибок (наличие обоснования). | ||
| 16 | |||
| 17 | Дополнительный вопрос: Достаточно ли хранимой и логируемой информации для понимания причины ошибки, воспроизведения ее на тестовом окружении? | ||
| 18 | ))) | ||
| 19 | |5|(% style="width:256px" %)Примеры и вопросы|(% style="width:1208px" %)((( | ||
| 20 | |(% style="width:273px" %)У нас есть Web Api, обрабатывающее входные запросы.|(% style="width:916px" %)((( | ||
| 21 | Учтены ли в контракте API ситуации, когда запрос завершается ошибкой (причем также могут допускаться разные типы), отражено ли это в формате ответа. | ||
| 22 | |||
| 23 | Исходя из требований и ситуации: Насколько информативным должен быть текст ответа API в случае ошибки валидации входных данных. Проверяются ли входные данные целиком или же обработка прекращается при нахождении первого недопустимого элемента? | ||
| 24 | ))) | ||
| 25 | |(% style="width:273px" %)У нас есть входная очередь и воркер, выполняющий чтение и обработку.|(% style="width:916px" %)((( | ||
| 26 | Существуют ли какие либо ошибки, возникновение которых должно приводить к тому, что мы перестаем извлекать новые сообщения, останавливая обработку (например до наступления какого-то события), или же воркер в любом случае должен переходить к обработке следующего сообщения? Сохранение информации о проблемном сообщении (сообщение привело к появлению ошибки). | ||
| 27 | |||
| 28 | В некоторых случаях может возникнуть вопрос необходимости периодической проверки доступности других сервисов или даже БД. И в случае недоступности менять поведение или останавливать обработку. | ||
| 29 | ))) | ||
| 30 | ))) | ||
| 31 | |||
| 32 | ---- | ||
| 33 | |||
| 34 | [[Логи, трассировка, мониторинг>>doc:Разработка.Логи, трассировка, мониторинг.WebHome]] | ||
| 35 | |||
| 36 | [[Open Telemetry>>doc:Разработка.Логи, трассировка, мониторинг.Open Telemetry.WebHome]] |