Is your feature request related to a problem? Please describe.
ISE should follow Python's Easier to Ask Forgiveness (EAFP) model of coding, by providing easier access to reasons that things fail. Currently, ISE throws a very generic ApiError when something goes wrong, and the reason for the error is hidden in text. So if one wants to follow EAFP, one is forced to do things like code something like this:
try:
api.endpoint.create_endpoint(mac=device_mac_address)
except ApiError as e:
try: # because you can't be sure that e has been properly populated
recheck=re.compile(".*already exists\.")
if re.match(e.details['ERSResponse']['messages'][0]['title']):
ok, endpoint doesn't exist
elif:
go through a lengthy list of possibilities
except:
we ate it because we didn't try to parse through the entire set of ApiError objects
That's a bit much.
Describe the solution you'd like
ESPECIALLY for CRUD sorts of errors, you should at least handle the basics in simple exceptions like:
- DeviceAlreadyExists (on create)
- NoSuchDevice (retrieval, update, delete)
- PermissionDenied (a generic auth/authz fail)
- TimeOut (my api object might be good, but the connection to ISE broke)
You can, if you want, subclass these from ApiError if you want to provide more readable detail
Describe alternatives you've considered
There are no easy workarounds, but one can at least take a guess on create_endpoint (for example) by first trying get_endpoint_by_name (or some such) and hoping that e.status_code is giving you something sane.
Is your feature request related to a problem? Please describe.
ISE should follow Python's Easier to Ask Forgiveness (EAFP) model of coding, by providing easier access to reasons that things fail. Currently, ISE throws a very generic ApiError when something goes wrong, and the reason for the error is hidden in text. So if one wants to follow EAFP, one is forced to do things like code something like this:
That's a bit much.
Describe the solution you'd like
ESPECIALLY for CRUD sorts of errors, you should at least handle the basics in simple exceptions like:
You can, if you want, subclass these from ApiError if you want to provide more readable detail
Describe alternatives you've considered
There are no easy workarounds, but one can at least take a guess on create_endpoint (for example) by first trying get_endpoint_by_name (or some such) and hoping that e.status_code is giving you something sane.