Re: [Qemu-devel] [PATCH 7/9] qdev: Use QError for not found error

[Markus Armbruster]

Luiz Capitulino <address@hidden> writes:

> Signed-off-by: Luiz Capitulino <address@hidden>
> ---
>  hw/qdev.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/qdev.c b/hw/qdev.c
> index 906e897..3ce48f7 100644
> --- a/hw/qdev.c
> +++ b/hw/qdev.c
> @@ -28,6 +28,7 @@
>  #include "net.h"
>  #include "qdev.h"
>  #include "sysemu.h"
> +#include "qerror.h"
>  #include "monitor.h"
>  
>  static int qdev_hotplug = 0;
> @@ -176,8 +177,7 @@ DeviceState *qdev_device_add(QemuOpts *opts)
>      /* find driver */
>      info = qdev_find_info(NULL, driver);
>      if (!info) {
> -        qemu_error("Device \"%s\" not found.  Try -device '?' for a list.\n",
> -                   driver);
> +        qemu_error_structed(QERR_QDEV_NFOUND, "{ s: s }", "name", driver);
>          return NULL;
>      }
>      if (info->no_user) {

And here we pay the price for structured error objects: reporting an
error becomes more difficult.  The harder you make reporting errors, the
fewer errors get caught and reported.  Also, the result is harder to
read.

If we need the structure, then it's just a price we have to pay.  Do we
need it?

In the example above, it gets us two pieces of information in addition
to the "monitor command failed" bit: the error code, which tells us the
exact kind of failure, and a data object to go with the error code, in
this case containing the name of the device.

Now let's look at errors from the client's perspective.

Clients need to classify errors to figure out how to respond to them.
Something like client error (i.e. your command was stupid, and trying
again will be just as stupid), permanent server error (it wasn't stupid,
but I can't do it for you), transient server error (I couldn't do it for
you, but trying again later could help).

Some classical protocols (HTTP, FTP) provide error class (they cleverly
encode it into the error code).  This gives clients a chance to sanely
handle errors they don't know.

Even with error class figured out, clients may still be interested in
the exact error code, at least in some cases.

They may also be interested in a human readable description of the
error, to present to their human users.  Some classical protocols
provide that in addition to an error code.  This gives clients a chance
to sanely report errors they don't know to human users.

I suspect that the additional error data is the error's least
interesting part most of the time.  When we get QERR_QDEV_NFOUND, I
figure it's usually clear what device we were trying to find.

But these are just my educated guesses.  I'd love to hear what folks
involved with actual clients have to say.  Anyone from libvirt?