Re: [Qemu-devel] [PATCH 00/10]: QError v4

[Luiz Capitulino <lcapitulino@redhat.com>]

On Sun, 22 Nov 2009 10:08:16 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> I'm certainly willing to consider alternative ways to do qmp_error() but 
> taking a free form string is not an option in my mind. It goes against 
> the fundamentals of what we're trying to build with QMP.

 Agreed.

> So if you're opposed to structured error data, just having 
> qmp_error(error_code) is a reasonable alternative. I don't think it's 
> the right thing to do, but I think it's still within the spirit of the 
> goals of QMP.

 You mean, we would have calls like:

qemu_error_new(error_code, 'device '%s' not found', name);

 and on the wire:

{ "error": 1234 }

 Did I get it right?

 If so, I can see some problems with it:

1. It's impossible to know what 1234 means by watching the
   protocol on the wire. Although this is a machine protocol,
   this is a good feature

2. We may have errors where having the error data is needed,
   and iirc someone gave an example of this some hundreds
   of emails ago

3. A new error will require a new code. Classes have the
   advantage of becoming stable over time and we'll end up
   just automatically reusing existing ones

 Note that (3) can make class-based error _easier_ to use
as there won't be the need to create new classes over time.

 This is not true for code-based errors. To guarantee there
are no duplicates, we'll have to centralize them in qerror.h,
this means that an enum will have to be updated for *each*
created error.

 I should also say that we're reaching the point where seeing
the current proposal work in practice would be more productive
then discussing it in theory.