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

Exceptions #7

Open
paulbarbu opened this issue Jun 23, 2012 · 2 comments
Open

Exceptions #7

paulbarbu opened this issue Jun 23, 2012 · 2 comments
Labels
harder idea up for grabs Maintainer has no plans to work themselves. Feel free to tackle.

Comments

@paulbarbu
Copy link
Contributor

Wouldn't it be more elegant to raise exceptions when something goes wrong, instead of returning touples?

Just saying... it would be more OOPish.

I can help, just let me know if it would be OK, so I don't invest time for nothing.

I could also look into #4.

@mrtazz
Copy link
Member

mrtazz commented Jun 24, 2012

I don't think using exceptions instead of returning tuples will buy us anything for the general API methods. In most cases it's a direct call to e.g. get a note and not getting it is not really an exception but can happen rather regularly (I'm usually encountering a lot of failed API calls from the Simplenote API). So it would change the existing API a fair bit, but not really give us a big advantage.

The authentication bug (issue #4) on the other hand could really benefit from raising an exception in the authenticate method whenever we get a failed login from the API. I think something like SimplenoteLoginFailed should do the job here.

@paulbarbu
Copy link
Contributor Author

Exceptions would make the API more usable, instead having to deal with a tuple as a retval, you can just enclose your code in try: except:, also you wouldn't have to check every time for a negative status code.

Also the fact that get_note (only an example) can return some exception I think is not semantically correct.

@ghost ghost assigned mrtazz Sep 25, 2012
@atomicules atomicules added the up for grabs Maintainer has no plans to work themselves. Feel free to tackle. label Jun 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
harder idea up for grabs Maintainer has no plans to work themselves. Feel free to tackle.
Projects
None yet
Development

No branches or pull requests

3 participants