It's incredibly unintuitive how to catch errors stemming from failed lookups in managers.py vs client.py. I've been burned many times now by trying to catch EntityNotFound, when the raised exception is actually GetError:
try:
resp = some_method_that_interacts_with_api()
except EntityNotFound:
# handle ...
EntityNotFound is not used at all in client.py - it is exclusively used in managers.py, and vice versa for GetError. This is a confusing dichotomy, when they are both some sort of GET request error, be it client-side or server-side.
Solution
All lookup-related exceptions should inherit from GetError so we can catch all lookup-related errors via GetError.
class EntityNotFound(GetError):
# ...
try:
resp = some_method_that_interacts_with_api()
except GetError:
# handle ...
Furthermore, after fixing this inheritance, we should consider explicitly raising EntityNotFound instead of GetError on 404 in client.py. Since EntityNotFound at that point inherits from GetError, we will not break consumers that expect GetError from 404 errors.
It's incredibly unintuitive how to catch errors stemming from failed lookups in managers.py vs client.py. I've been burned many times now by trying to catch
EntityNotFound, when the raised exception is actuallyGetError:EntityNotFoundis not used at all in client.py - it is exclusively used in managers.py, and vice versa forGetError. This is a confusing dichotomy, when they are both some sort of GET request error, be it client-side or server-side.Solution
All lookup-related exceptions should inherit from
GetErrorso we can catch all lookup-related errors viaGetError.Furthermore, after fixing this inheritance, we should consider explicitly raising
EntityNotFoundinstead ofGetErroron 404 in client.py. SinceEntityNotFoundat that point inherits fromGetError, we will not break consumers that expectGetErrorfrom 404 errors.