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

["Daniel P. Berrange" <berrange@redhat.com>]

On Mon, Oct 19, 2009 at 09:00:33AM -0500, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >hink just returning error codes to the client is far too little
> >information. I don't think we need the fully normalized structure
> >that Luiz originally proposed with bus/dev addresses split out, but
> >we certainly need to include a string description giving as much
> >detail as possible.  If attaching a host USB device failed, I don't
> >want a single error code  QERR_OPEN_FAILED, nor a generic message 
> >like 'could not open device', i want the exact details, eg
> >
> >  'could not open device: permission denied' 
> >  'could not open device: no such file or directory' 
> >  'could not open device: device or resource busy' 
> >
> >The localization issue is somewhat of a red herring though. This string
> >description is not something that clients would ultimately expose to the
> >user. The client apps would likely present a more generic error message
> >to the user, based off the error code. The error description received
> >from QEMU will instead be written out to the logs as a record for later
> >troubleshooting. eg if the user files a bug report, it will include the
> >full error details, so libvirt/qemu maintainers have a better chance of
> >figuring out what went wrong.
> >  
> 
> But then advanced users end up doing silly things like analyzing libvirt 
> logs.  Why do that when your own example is obviously "could not open 
> device: %s", strerror(errno).   We should pass {"error" : {"type": 
> "OpenFailedException", "errno": errno}}

Having a named "exception" instead of an error code is fine, but I think
it is overkill to include fully-structured data fields like 'errno' instead
of just a string. The libvirt application API has a insanely detailed 
error object allowing for passing of structured data back to apps, but 
I'm not aware of any application that has ever used it.  They all just
hook on the error code, and log/print detailed string message field. 

In terms of libvirt using QMP error data, there may be one or two
places where we'd toggle behaviour off an error code / exception type,
but any futher structured data would likely just be converted to a generic
string message. So I don't see much need for anything beyond a error code
or exception type to be used for behaviour decisions, and a detailed string
description for logging.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|