incubator-libcloud mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <p...@querna.org>
Subject Re: [libcloud] ideas on improving exceptions usage
Date Thu, 05 Aug 2010 17:57:04 GMT
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
View raw message