Обработка ошибок проверки подписки

Question

В настоящее время я пытаюсь обработать исключение, когда запрос на подписку не может быть проверен во времени с помощью Graph SDK.К сожалению, я не совсем уверен, как этого добиться.Исключение, которое выдается, когда подписка не проверяется во времени:

Microsoft.Graph.ServiceException: Код: InvalidRequest Сообщение: сбой запроса на проверку подписки.Необходимо ответить 200 OK на этот запрос.

HttpStatusCode в ServiceException - "BadRequest", но только этого недостаточно, чтобы отличить ошибку от других распространенных ошибок, так как яхочу обращаться с ними по-другому.ServiceException также содержит свойство Error со строковым свойством под названием «Код», которое в моем случае содержит «InvalidRequest».Перечисление GraphErrorCode в Graph SDK содержало этот код, поэтому я использовал его с методом "IsMatch" в ServiceException:

catch (ServiceException serviceException)
{
     var invRequest = GraphErrorCode.InvalidRequest.ToString();
     if(serviceException.StatusCode == HttpStatusCode.BadRequest)
     {
          if (serviceException.IsMatch(invRequest))
          {
              // do something
          }
      }
}

"InvalidRequest" определен в графе документация как:

Запрос искажен или неверен.

Учитывая это, я все еще думаю, что моего ErrorHandling недостаточно, чтобы просто перехватить эту конкретную ошибку.

Что я хочу знать:

• Использует ли перечисление "GraphErrorCode" даже правильно.

• Есть ли способчтобы обработать эту конкретную ошибку без простого сравнения сообщения об исключении («Запрос проверки подписки не выполнен. Необходимо ответить 200 на этот запрос») с жестко закодированной строкой.

Answer 1

Вы ссылаетесь на устаревшую библиотеку (более 2 лет).Правильный SDK для этого - Клиентская библиотека Microsoft Graph .NET .Он включает в себя более свежую нумерацию кода ошибки .

Что касается обработки ошибки, то кода обычно достаточно для обработки исключений.Содержимое сообщения полезно для отладки, поскольку оно часто содержит более детальную информацию (что именно не удалось, какие свойства были недействительными и т. Д.).Мое общее правило - использовать code для обработки ошибок, но регистрировать оба свойства code и message для отладки.

Важно понять, что разные конечные точки могут отображать один и тот же код ошибки по разным причинам.BadRequest может означать что-то иное при выдаче GET для ресурса user, чем при выдаче от POST до /events.Ваш обработчик должен учитывать как action , так и error .

Вот пример ошибки, возвращаемой при отправке неверного запроса (/v1.0/me/a):

{
    "error": {
        "code": "BadRequest",
        "message": "Unsupported segment type. ODataQuery: users/48d31887-5fad-4d73-a9f5-3c356e68a038/a",
        "innerError": {
            "request-id": "fd4c8b27-26af-4b07-a5be-5efb139d1eb7",
            "date": "2018-05-22T14:39:02"
        }
    }
}

Если бы все, что я обработал, было BadRequest, мой обработчик, вероятно, был бы достаточно.Я могу обработать ошибку и заставить пользователя двигаться вперед.Однако в моем журнале я храню как BadRequest, так и Unsupported segment type. ODataQuery: users/48d31887-5fad-4d73-a9f5-3c356e68a038/a, чтобы я мог правильно сообщить об ошибке в коде.

Другим вариантом может быть дополнительный анализ.Допустим, /a не всегда не возвращает ошибку.Возможно /a отлично работает для учетных записей AAD, но не для пользователей MSA (FTR, /a полностью вымышлен).Если бы это было так, я мог бы также проанализировать message и посмотреть, включает ли BadRequest «Неподдерживаемый тип сегмента», и обработать его немного иначе, чем BadRequest, который не включал это сообщение.