okfn/dpm — Issue #25: dpm Exceptions
Author: dgraziotin
Created: 2011-11-07 18:35:20+00:00
State: open

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](https://github.com/okfn/dpm/blob/master/dpm/index/ckan.py#L46)). 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.