У меня есть функция Azure (триггер HTTP), которая может дать сбой. Я также настроил для него Application Insights.

В случае ошибки (что лучше):

  1. Перехватите исключение, оберните его дополнительной информацией и повторите его. (отправляет ответ 500) ИЛИ
  2. Поймать исключение, зарегистрировать его, обернуть, повторно передать вызывающему. (отправляет ответ 500) ИЛИ
  3. Перехватите исключение, зарегистрируйте его (не выбрасывайте), вручную отправьте ответ 500.

Application Insight может регистрировать исключения. Я действительно не вижу смысла в регистрации ошибки и одновременном исключении исключения.

Каковы рекомендации? Что такое хорошая практика?

16
Hooch 12 Ноя 2019 в 16:13
Есть две статьи по обработке исключений, на которые я часто ссылаюсь и считаю обязательным к прочтению: blogs.msdn.microsoft.com/ericlippert/2008/09/10/… | codeproject.com/Articles/9538/… | Веб-ошибки, как правило, относятся к «экзогенной» части спектра, начиная с первой статьи. | Если (и когда) вы должны обернуть, обсуждается во 2-м.
 – 
Christopher
12 Ноя 2019 в 16:16
Я помню недавний вопрос, где упаковка была полезна. Мы получили IOException с сообщением, которое явно было из исключения аргумента (параметр функции равен нулю или что-то в этом роде). Таким образом, он, вероятно, обернулся вокруг исходного ArgumentException. Это добавило «Синтаксическое значение», потому что теперь я знал, что Исключение Аргумента произошло где-то в коде ввода-вывода.
 – 
Christopher
12 Ноя 2019 в 16:19
Хуч, каков ваш предпочтительный подход на данный момент? Разрешить инфраструктуре приложения-функции регистрировать возникшее исключение в подключенной AppInsights?
 – 
dbardakov
26 Окт 2020 в 15:47

1 ответ

Из моего опыта создания лазурной функции, запускаемой HTTP, с помощью Python, я заметил, что: при обработке исключений и последующем ручном возврате чего-либо клиенту у вас есть контроль над возвращаемым значением функции, но платформа помечает задание функции как «Успешное», что затем затрудняет отслеживание и мониторинг в Application Insights.

Что касается вашего вопроса, я получил предложение catch, которое смешивает 1 и 3, то есть гибридный подход, когда я пытаюсь определить источник исключения, затем для исключений из моего кода я упаковываю его и возвращаю 500, а для других исключений который возник из кода, который я использую, я повторно выбрасываю их и позволяю платформе функций Azure возвращать 500 и помечать задание функции как «Неудачное».

1
ben cohen 11 Янв 2021 в 17:33