You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: