On 6/28/19 7:31 AM, Richard W.M. Jones wrote: > This kind of fixes the problems in v1. The exception still primarily > lives in the libnbdmod and you could still refer to it using > libnbdmod.Error (but don't do that). However when the exception is > printed it now appears as nbd.Error, and you can catch it also using > the same name. > > Other problems: > > - There is no "nice" interface to accessing the exception fields. > You have to use ex.args[0] and ex.args[1].
I think we can make it nicer with a bit of effort - we just need to figure out how to tie in an __init__ method that parses the args tuple and assigns direct attributes (the args tuple will always be there, since we inherit that from the Exception base class, but adding our own local attributes makes access easier). We may also want a __str__ method for sanely printing the contents of our exception. > > - The errno is represented as a number, which means it will be hard > to write portable Python code depending on the errno. Not that difficult. The standard python error module can doe reverse lookup error.errorcode[integer] to give you the string 'EINVAL' (if integer has the same value as errno.EINVAL). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Libguestfs mailing list [email protected] https://www.redhat.com/mailman/listinfo/libguestfs
