incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Davis <...@dislocatedday.com>
Subject Re: [libcloud] ideas on improving exceptions usage
Date Thu, 05 Aug 2010 18:11:50 GMT
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 <paul@querna.org> wrote:

> On Thu, Aug 5, 2010 at 10:44 AM, Roman Bogorodskiy
> <bogorodskiy@gmail.com> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message