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

dpm Exceptions #25

Open
dgraziotin opened this issue Nov 7, 2011 · 0 comments
Open

dpm Exceptions #25

dgraziotin opened this issue Nov 7, 2011 · 0 comments

Comments

@dgraziotin
Copy link
Contributor

How much sense does it have to create some custom exceptions for dpm?
There are many methods in dpm that do not return a type (i.e., "void methods" or procedures). The library is reflecting this programming style. It is fine, but not safe. Moreover, exceptions should be checked in tests, IMHO.

These procedures should at least raise exceptions on failure. Dpm lacks some exception raises in some parts. A documented example is here). In this case, the exception to be raised seems clear, but there are other parts in which we don't know what to expect or raise.

There are three possible abstraction levels on which we may work on:

  • Create a dpm Exception and subclasses
  • CKAN exceptions (I still must study them)
  • Python built-in exceptions

Of course the first one is the most elegant for the library and the whole project, but requires some work. Exceptions should also be checked when testing.
I would like to discuss about it. It's a boring work, but when a decision is taken I may take care of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant