Re: [Qemu-devel] [PATCH v1 00/14]: Initial QObject conversion

[Gerd Hoffmann <kraxel@redhat.com>]

   Hi,
>
>> So maybe they shouldn't be named MonitorError in the first place?
>
>   What do you suggest?
>
>   Hm.. This could be QError, meaning that it's also a QObject,
> so that we can put it in dicts, lists, etc.

Makes sense to me.

Attaching the pretty-print callback to the error struct not to the 
monitor command is a good move too.  Makes it easier to reuse these 
functions.

Hmm, maybe it would be even better to link the pretty-print functions to 
error codes?

>> Why user_error is needed in the first place btw?  To maintain
>> backward-compatible error message formating?
>
>   Yes and to do pretty printing too.
>
>   For example:
>
> qemu_error("Device \"%s\" not found.  Try -device '?' for a list.\n",
>             driver);
>
>   Makes sense for humans, but for QMP it would probably look like:
>
> { "error": { "code": 1234,
>               "desc": "device not found",
>               "data": { "name": "foobar-device" } } }

You could have a generic function which makes a message like this:

   'device not found: name=foobar-device'

out of the QError.  Not too bad.  You'll loose the '-device ?' hint though.

I think it is reasonable to make the pretty-print callback optional and 
use the generic function in case it isn't present.  So you have 
something working by default and can override it of the message isn't 
userfriendly or backward-compatible enougth.

>   So, when QMP is disabled that function will be called to print the error
> for humans. When QMP is enabled this is never called and the protocol
> emission code will use QError to emit something like the { "error" }
> dict above.

Thanks for the explanation.

cheers,
   Gerd