Mailing List Archive

On Thu, May 18, 2006 at 12:31:53PM -0700, Kaleb Pederson wrote:

> Hello,
>
> I don't see any way to get at the exception class that is being used by
> xen.lowlevel.xc. I wanted to be able to grab just the xen exceptions,
> but it doesn't appear possible:
>
> >>> import xen.lowlevel.xc as xc
> >>> dir(xc)
> ['__doc__', '__file__', '__name__', 'xc']
> # the only thing listed is the xc class
>
> # i'm running 3.0.2 using the sedf scheduler, so this should fail
> >>> try:
> ... x.bvtsched_domain_get(0)
> ... except Exception, e:
> ... print e.__class__
> ... print dir(e)
> ... print dir(e.__class__)
> ... print e.__module__
> ... print e.args
> ...
> xen.lowlevel.xc.error
> ['__doc__', '__getitem__', '__init__', '__module__', '__str__',
> 'args']
> ['__doc__', '__getitem__', '__init__', '__module__', '__str__']
> xen.lowlevel.xc
> (22, 'Invalid argument')
> >>> e
> <xen.lowlevel.xc.error instance at 0xb7b78b2c>
> >>> xc.error
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> AttributeError: 'module' object has no attribute 'error'
>
> Did I miss something? If not, could the xen.lowlevel.xc.error class be
> publically exposed?

They are exceptions of the built-in type RuntimeError -- that's what you get
when you use PyErr_SetFromErrno in the C layer. I don't know why it shows up
as xc.error -- presumably that's a Python internal thing.

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thursday 18 May 2006 3:14 pm, Ewan Mellor wrote:
> On Thu, May 18, 2006 at 12:31:53PM -0700, Kaleb Pederson wrote:
[snip]
>
> They are exceptions of the built-in type RuntimeError -- that's what you
> get when you use PyErr_SetFromErrno in the C layer. I don't know why it
> shows up as xc.error -- presumably that's a Python internal thing.

So this should work, but doesn't either:

>>> import xen.lowlevel.xc as xc
>>> import exceptions
>>> x = xc.xc()
>>> try:
... x.bvtsched_domain_get(0)
... except exceptions.RuntimeError, e:
... print "Caught RuntimeError"
...
Traceback (most recent call last):
File "<stdin>", line 2, in ?
xen.lowlevel.xc.error: (22, 'Invalid argument')

I also confirmed with isinstance, and exception is the only one of
exceptions.* that it inherits from.

I'm not familiar with the Python C API at all, but I did a bit of digging
around:

from tools/python/xen/lowlevel/xc/xc.c:

...
#define PKG "xen.lowlevel.xc"
...
xc_error = PyErr_NewException(PKG ".error", NULL, NULL);
...

So, the name displayed (xen.lowlevel.xc.error) is defined based on the call
above. I found the python docs for PyErr_NewException:

"
PyObject* PyErr_NewException( char *name, PyObject *base, PyObject *dict)
Return value: New reference.
This utility function creates and returns a new exception object. The name
argument must be the name of the new exception, a C string of the form
module.class. The base and dict arguments are normally NULL. This creates a
class object derived from the root for all exceptions, the built-in name
Exception (accessible in C as PyExc_Exception). The __module__ attribute of
the new class is set to the first part (up to the last dot) of the name
argument, and the class name is set to the last part (after the last dot).
The base argument can be used to specify an alternate base class. The dict
argument can be used to specify a dictionary of class variables and methods.
"

So, per the docs, it is only derived from Exception. It would be much nicer
if it were derived from some other exception class... say XenException or
something....

Thanks.

--Kaleb

Ewan Mellor wrote:
>> Did I miss something? If not, could the xen.lowlevel.xc.error class be
>> publically exposed?
>>
>
> They are exceptions of the built-in type RuntimeError -- that's what you get
> when you use PyErr_SetFromErrno in the C layer. I don't know why it shows up
> as xc.error -- presumably that's a Python internal thing.
>

Actually, these exceptions are rather weird. This is pretty much
pushing my Python understanding to the limit but I looked into this a
while back and came to this conclusion.

These are not RuntimeError exceptions but rather of the type xc.error.
This type is created in initxc() with PyErr_NewException().

The weird thing is, this type is not exposed through the modules export
list so you cannot ever directly reference the type. However, type() of
the exception will return xc.error.

The PyErr_SetFromErrno is just a helper that instantiates an exception
of a given type and sets the value of the exception to a tuple
containing the errno and message.

As a hack, I changed xc_error to be initialized to PyExc_OSError which
allowed errors to be caught appropriately. I don't know if this is the
Right Thing to do from a Python perspective (if libxc were in Python,
the failures would get propagated as OSErrors so it sort of makes sense).

In the very least, we probably have to somehow expose the exception type
within the module. It's quite unfortunately that everywhere in Xend
just catches any exception.

Any Python gurus out there that can shed some light on the proper thing
we should be doing? It's an easy patch once we know what the right
thing to do is.

Regards,

Anthony Liguori

> Ewan.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, May 19, 2006 at 01:53:11AM -0500, Anthony Liguori wrote:

> Ewan Mellor wrote:
> >>Did I miss something? If not, could the xen.lowlevel.xc.error class be
> >>publically exposed?
> >>
> >
> >They are exceptions of the built-in type RuntimeError -- that's what you
> >get
> >when you use PyErr_SetFromErrno in the C layer. I don't know why it shows
> >up
> >as xc.error -- presumably that's a Python internal thing.
> >
>
> Actually, these exceptions are rather weird. This is pretty much
> pushing my Python understanding to the limit but I looked into this a
> while back and came to this conclusion.
>
> These are not RuntimeError exceptions but rather of the type xc.error.
> This type is created in initxc() with PyErr_NewException().
>
> The weird thing is, this type is not exposed through the modules export
> list so you cannot ever directly reference the type. However, type() of
> the exception will return xc.error.
>
> The PyErr_SetFromErrno is just a helper that instantiates an exception
> of a given type and sets the value of the exception to a tuple
> containing the errno and message.

Yes, you're right, my mistake. The ones in xs.c do
PyErr_SetFromErrno(PyExc_RuntimeError), that's where I got that from.

> As a hack, I changed xc_error to be initialized to PyExc_OSError which
> allowed errors to be caught appropriately. I don't know if this is the
> Right Thing to do from a Python perspective (if libxc were in Python,
> the failures would get propagated as OSErrors so it sort of makes sense).
>
> In the very least, we probably have to somehow expose the exception type
> within the module. It's quite unfortunately that everywhere in Xend
> just catches any exception.
>
> Any Python gurus out there that can shed some light on the proper thing
> we should be doing? It's an easy patch once we know what the right
> thing to do is.

If we're going to make a change at all, we ought to do it properly. We should
have an exception for each of the xc and the xs modules, exposed through the
module interface correctly. I don't have a problem with the exception being
derived directly from Exception, though if we're going to change xs.c as well
as xc.c, then we ought to inherit from RuntimeError, for compatibility with
the Python layer.

Can one of you two submit a patch?

Cheers,

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel