it-roy-ru.com

Правильно ловить ошибки boto3

Я занимаюсь разработкой приложения Django, которое взаимодействует с несколькими веб-сервисами Amazon.

До сих пор у меня возникают проблемы с обработкой и отловом исключений, выдаваемых клиентом boto3. То, что я делаю, кажется излишне утомительным:

Пример:

client = boto3.client('sns')
client.create_platform_endpoint(PlatformApplicationArn=SNS_APP_ARN, Token=token)

это может вызвать botocore.errorfactory.InvalidParameterException, например, знак плохой.

client.get_endpoint_attributes(EndpointArn=endpoint_arn)

может бросить botocore.errorfactory.NotFoundException.

Во-первых, я не могу найти эти ошибки нигде в коде, поэтому они, вероятно, где-то сгенерированы. Итог: я не могу импортировать это и поймать это как обычно.

Во-вторых, я нашел один способ отловить ошибку здесь , используя:

try:
    # boto3 stuff
except botocore.exceptions.ClientError as e:
    if e.response['Error']['Code'] == 'NotFound':
        # handle exception
    else:
        raise e

Но я должен удалить часть имени ошибки Exception. Кажется очень случайным, и я понятия не имею, хочу ли я удалить Error в botocore.exceptions.ParamValidationError, если я хочу поймать это. Так что сложно обобщать.

Другой способ отловить ошибку - использовать объект клиента boto3, который я получил:

try:
    # boto3 stuff
except client.exceptions.NotFoundException as e:
    # handle exception

Это кажется самым чистым способом до сих пор. Но у меня не всегда есть клиентский объект boto3, где я хочу поймать ошибку. Кроме того, я до сих пор только пробую что-то, так что это в основном работа с догадками.

Кто-нибудь знает, как ошибки boto3 должны обрабатываться?

Или может указать мне на какую-то последовательную документацию, в которой упоминаются ошибки выше? Спасибо

8
David Nathan

Вы хорошо суммировали ситуацию. У старой boto был простой жестко заданный подход к поддержке API-интерфейсов AWS. boto3, что, по-видимому, является попыткой уменьшить накладные расходы на синхронизацию клиента Python с развивающимися функциями на различных API-интерфейсах, было более гибким в отношении исключений, поэтому подход ClientError, который вы описали выше, раньше был каноническим.

В 2017 году они представили второй механизм, который вы выделили: «смоделированные» исключения, доступные на клиенте.

Я не знаком с SNS, но по своему опыту работы с другими продуктами AWS именование ClientError соответствует HTTP-API, которые, как правило, хорошо документированы. Поэтому я бы начал здесь: https://docs.aws.Amazon.com/sns/latest/api/Welcome.html

Похоже, что смоделированные исключения нового стиля генерируются из файлов определения сервиса, которые находятся в модуле botocore. Я не могу найти какую-либо документацию об этом, но просмотрите модели сервисов AWS в https://github.com/boto/botocore/tree/master/botocore/data .

Кроме того, полезно знать, что если вы (в отличие от кода OP) не имеете дела непосредственно с клиентом низкого уровня, а вместо этого используете высокоуровневый объект AWS ServiceResource, клиент низкого уровня по-прежнему легко доступен по адресу my_service_resource.meta.client так что вы можете обрабатывать исключения следующим образом:

try:
    my_service_resource.do_stuff()
except my_service_resource.meta.client.exceptions.NotFoundException as e:
    # handle exception
3
ben author