I really like this idea. libcloud-based exceptions should be easier to catch and handle (meaning include driver, url, http status if applicable, message, etc.) I don't see a big win in having driver-specific exceptions as it's just more boilerplate; including the driver should be sufficient for most cases.
On Thu, Aug 5, 2010 at 1:57 PM, Paul Querna <[email protected]> wrote: > 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 >
