Library should throw our own exceptions

[smulube]

This is related to the initial issue raised here: #1

I don't think we should just throw naked exceptions from the Requests library on errors; that means that if client programs are using the Xively library, they also have to import exceptions from Requests if they want to handle errors in any sort of fine grained detail. I don't think clients should have to care what HTTP library we are using under the hood, so I think we should raise our own errors on failures.

In fact I have some example code that does that that I'll try to clean up and attach to this issue.

@gnublade

[gnublade]

I'm working on wrapping some exceptions that it makes sense to (namely 404s), and I take your point but I'm not sure I entirely agree. We shouldn't hide the fact that we are using the requests library under the hood, and in fact if you need to access CSV, XML, or PNGs directly this is done with the low level client which returns a requests.Response object.

How about instead we export the request exceptions from the xively namespace:

>>> from zively.exceptions import HTTPError

[smulube]

Hmm, interesting to hear that perspective. I guess what I was thinking was to have a bunch of our own errors. i.e.:

class ClientError(Exception):
class ApiError(Exception):

class NotFound(ApiError):
    STATUS_CODE = 404

class Forbidden(ApiError):
    STATUS_CODE = 403

class ApiKeyRequired(ClientError):
    pass

or something like that. How would exporting the Requests exceptions work? Does that bring all those exceptions into the xively namespace?