|
From: | Anthony Liguori |
Subject: | [Qemu-devel] Re: [RFC 0/7] QError v1 |
Date: | Fri, 30 Oct 2009 08:59:43 -0500 |
User-agent: | Thunderbird 2.0.0.23 (X11/20090825) |
Luiz Capitulino wrote:
Seems ok to me, but to make it harder to reuse existing error codes we'd have to: 1. Make mandatory the use of a macro in the qemu_error_structed() call 2. All macros would have to be defined in qerror.h
Not really. All you need is to switch code to something that's more easily definable like a string. So...
#define QERR_DEV_NFOUND "{ 'code': 'DevNotFound', 'name': %s}" Now you can define this anywhere.
Btw, why are you calling it qemu_error_structured()? It's a long name, let's call it qemu_erro_structed() or any better name.. I thought about qemu_error_throw()..
How about qemu_error_new(). It returns a QObject and I assume we'll just return an error object instead of returning a normal result, correct?
I agree that a bit more generic error messages wouldn't be a bad thing.I think we're back to the discussion regarding what information an error should contain. Daniel seems to want as most info as possible: http://lists.gnu.org/archive/html/qemu-devel/2009-10/msg01640.html In case we put only the error code and error data on the wire, I think error codes should be *unique* and not generic. This way clients are able to determine the exact error cause. If we go with generic errors, then we would have to send the user string along. This introduces the problem of localization and can be a bit redundant, as the call above would be emitted like: { "error": { "code": 404, "desc": "driver foobar not found", "data": { "name": foobar" } } }
I think this is a problem that we don't have to solve yet. Let's get the error format down first and then we can consider how granular the errors ought to be.
Changing the types of errors thrown is easy to do without breaking compatibility.
-- Regards, Anthony Liguori
[Prev in Thread] | Current Thread | [Next in Thread] |