On Fri, Mar 23, 2007 at 01:28:36PM +0000, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
>Actually looks like it is the generated code actually. The generator.py
>appears to only add in the 'raise libvirtError' stuff if the return value
>is a virConnectPtr/virDomainPtr/virNeworkPtr object - any other function
>with a non-object return value gives back None upon error.
The generator.py code as it stands doesn't deal with the case where a
function is prototyped (in C) as returning 'int'.
If I were to modify generator.py so that it adds the check for functions
returning int, then it doesn't work because there is not enough
information from just the C return type to tell what the Python return
type will be.
Right and that's why the automatic generator does not raise exception
automatically. For example getMaxMem could return -1 to mean unlimited
(e.g. on Domain 0) which is a correct return code in my opinion and
should not be considered and error, while getMem returning -1 should
really mean an error occured.
No way automatic code could catch the subtle difference.
We could do some run-time type magic in the generated wrapper,
although
that seems evil.
At best keep a list of functions where one would not want to generate
exception automatically.
We could possibly drop the generator but it still has quite some value
to me as long as the interfaces evolve, or even the documentation of function
since the python binding modules gets the comments directly from the
comments in the C code. It's easy to dismiss the generators because of it's
limitations but it really lowers the maintaince and preserve accuracy over
long term (at least that's my experience).
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/