Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Follow EAFP where possible #63

Open
elear opened this issue Mar 1, 2024 · 0 comments
Open

Follow EAFP where possible #63

elear opened this issue Mar 1, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@elear
Copy link

elear commented Mar 1, 2024

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.

@bvargasre bvargasre added the enhancement New feature or request label Jul 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants