Re: [Qemu-devel] [RFC 0/5] Monitor handlers convertion to QObject

[Gerd Hoffmann <kraxel@redhat.com>]

   Hi,

>   Some people have suggested us to define errors codes, but I dislike this
> because I have the impression we will end up defining errors per-handlers,
> which is a lot of work and more protocol definitions to maintain.

What about error messages?

I've recently added some infrastructure for error messages: 
qemu_error() + friends.  Intention is to direct error messages to the 
correct place, especially for code which can be called from multiple 
paths.  Device creation for example can be triggered by command line 
(errors should go to stderr) or via hotplug monitor commands (errors 
should go to the monitor).

You might want to add a third error sink which stuffs error messages 
into a Qstring, so you can pass them along as Qobject without the code 
emitting the error message knowing anything about it.

>   Another issue in this subject is that sometimes we will have to do
> a not so small refactor to get the proper error code. I mean, sometimes
> the functions which the handlers call return void, and those functions in
> turn call other functions which also return void. This seem to be the
> case of do_balloon(), for example.

There are also a few places which call exit(1) on error.  Which is ok 
when something goes wrong while creating the virtual machine, but not 
when some monitor command failed ...

>   A possible solution is to only return error when it's easy, otherwise we
> could always return 0 (which is what we have today), the problem though
> is that changing this in the future will cause trouble.

Serious code audit is more work initially, but I think we well be very 
happy we did it in the long run ...

cheers,
   Gerd