On Thu, Aug 5, 2010 at 10:44 AM, Roman Bogorodskiy <[email protected]> wrote: > Hello, > > Some time ago I brought an 'exceptions' topic on IRC, basically, I think > it would be nice to make exceptions more centralised and unified among > drivers. > > The general idea is to create some base exception, e.g. > LibCloudException and subclass all other exception from it. > > From a user perspective it will allow to identify libcloud exceptions > quite easily. > > My proposal is pretty simple: > > - just add LibCloudException to libcloud.types > - make other exceptions in libcloud.type be a subclass of > LibCloudException > - eventually convert all the drivers to this scheme > > I though about moving all the exceptions to a separate module but > considering that we have only handful of them I don't see much sense in > it. Also, I'm not sure it makes sense to introduce driver specific > exceptions... even if we need this we probably could introduce a > 'driver' property for LibCloudException which would show the driver an > exception came from. > > I've crafted a simple patch illustrating an idea: > > http://people.freebsd.org/~novel/misc/libcloud_exc.diff > > Comments are welcome, >
+1 in general, one of the problems we have definitely ran into is the diverse set of exceptions you get from every provider. I think we should try to include a little more meta-data in the base exception class, like the driver. Also in this specific example, I would like another specific exception, LibcloudMalformedResponseException or such, because this is one of the most common errors we see from various providers. We also will want another one for providers that return 500s or 400s to API calls, maybe LibcloudHTTPException, probably would be nice to include the response body / HTTP code in it. Happy to hack on it a bit, but I think you could commit the patch you have to trunk and we can iterate from there. -Paul
