ClientError feels very general

I’ve just started using boto3 (after years with the previous version) so I’ve been getting to grips with the new api today.

One thing that stuck out at me is how one needs to catch and inspect ClientError to determine existence when working at the resource level (eg https://boto3.readthedocs.org/en/latest/guide/migrations3.html#accessing-a-bucket).

Maybe I’m missing something but it feels like those various exceptions should be wrapped as more specific exceptions so they could at least be caught directly. Something along the lines of:

try:
    s3.meta.client.head_bucket(Bucket='mybucket')
except BucketNotFoundError as e:
    pass

As it stands it seems I need to do a bunch of 404 checks for testing if s3 keys exist etc. Maybe there’s a better way of doing it?

It does feel a little like the level of abstraction is a bit close to the underlying aws implementation - but maybe that’s the intention?

As ever, thanks for an amazing and solid bit of software.

[markddavidoff]

If anyone else ends up here looking for a list of error codes, the ClientError.response['Error']['Code'] error codes come from the aws sdk and can be found here

[kislyuk]

+1. I would prefer if an error class were vivified from ClientError.response[“error”][“code”], so instead of writing:

try:
    ...
except botocore.exceptions.ClientError as e:
    if e.response.get("Error", {}).get("Code") == "...":
        ...
    else:
        raise

or something else equally brittle and yucky, I could just write except botocore.exceptions.LimitExceeded, etc. If they all inherit from ClientError, this is a fully backward compatible change.