Комментарий

• Свойства страницы (1 изменено, 0 добавлено, 0 удалено)

Подробности

Свойства страницы

Содержимое

...	...	@@ -1,15 +1,30 @@
1		-
2		-1) Мы можем выделить несколько типов ошибок в модели приложения.
3		-Как миниму обычно можно выделить - технические ошибки и ошибки валидации входных данных (а также ошибки валидации недопустимых действий).
	1	+|1|(% style="width:256px" %)Введение типов ошибок.|(% style="width:1208px" %)(((
	2	+Наличие регламента типов ошибок.
	3	+Как минимум обычно можно выделить - технические ошибки и ошибки валидации входных данных (а также ошибки валидации недопустимых действий).
4	4	В целом модель типов ошибок может быть более сложной.
5	5
6		-2) При разработке приложение желательно определить политики того, как и какие ошибки мы будем передавать и перехватывать.
	6	+Это также позволит реализовать различную логику в зависимости от типа ошибки.
7	7
8		-3) Также важно понисать как ошибки влияю на жизненный цикл обработки запроса в нашем приложении. Какие ошибки являются критичными, а какие говорят о необходимости выполнить альтернативное действие.
	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	+За исключением того, если определен перечень допустимых ошибок (наличие обоснования).
9	9
10		-4) Логирование - не должно быть ситуации, когда технические ошибки могут просто пропасть, не попав в логи.
11		-Или же у нас есть перечень допустимых ошибок, а все остальное пишется в логи.
	17	+Дополнительный вопрос: Достаточно ли хранимой и логируемой информации для понимания причины ошибки, воспроизведения ее на тестовом окружении?
	18	+)))
	19	+|5|(% style="width:256px" %)Примеры и вопросы|(% style="width:1208px" %)(((
	20	+|(% style="width:332px" %)У нас есть Web Api, обрабатывающее входные запросы.|(% style="width:857px" %)(((
	21	+Учтены ли в контракте API ситуации, когда запрос завершается ошибкой (причем также могут допускаться разные типы), отражено ли это в формате ответа.
12	12
13		-5) Например: У нас есть WebApi, обрабатывающее входные запросы. Насколько информативным должен быть текст ответа API в случае ошибки валидации входных данных. Проверяются ли входные данные целиком или же обработка прекращается при нахождении первого недопустимого элемента?
	23	+Исходя из требований и ситуации: Насколько информативным должен быть текст ответа API в случае ошибки валидации входных данных. Проверяются ли входные данные целиком или же обработка прекращается при нахождении первого недопустимого элемента?
	24	+)))
	25	+|(% style="width:332px" %)У нас есть входная очередь и воркер, выполняющий чтение и обработку.|(% style="width:857px" %)(((
	26	+Существуют ли какие либо ошибки, возникновение которых должно приводить к тому, что мы перестаем извлекать новые сообщения, останавливая обработку (например до наступления какого-то события), или же воркер в любом случае должен переходить к обработке следующего сообщения? Сохранение информации о проблемном сообщении.
14	14
15		-6) Например: У нас есть входная очередь и воркер, выполнябщий чтение и процесинг. Существуют ли какие либо ошибки, возникновение которых должно приводить к тому, что мы перестаем извлекать новые сообщения, останавливая обработку (например до наступления какого-то события), или же воркер в любом случае должен переходить к обработке следующего сообщения? Храним ли мы в каком-либо месте полный текст входного сообщения (или достаточное кол-во данных), чтобы иметь возможность обработать его повторно или воспроизвести ситуацию на тестовом окружении.
	28	+В некоторых случаях может возникнуть вопрос необходимости периодической проверки доступности других сервисов или даже БД. И в случае недоступности менять поведение или останавливать обработку совсем.
	29	+)))
	30	+)))