On Sun, 22 Nov 2009 10:08:16 -0600 Anthony Liguori <anth...@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.