Daniel P. Berrange wrote:
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.
Just because the current consumers are lazy doesn't mean we should
restrict the API.
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.
While it gets complicated when going through things like libvirt, if we
design the python bindings for libqmp directly, these will appear as
proper exception objects with members corresponding to the data. I would
fully expect that users would use the structured exception data in a
language like Python. For instance, when changing a cdrom iso, being
able to handle EPERM and ENOENT separately is very valuable.
Regards,
Anthony Liguori
