qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: QError conversion problems: putting errors in context


From: Luiz Capitulino
Subject: [Qemu-devel] Re: QError conversion problems: putting errors in context
Date: Wed, 17 Feb 2010 17:23:17 -0200

On Mon, 15 Feb 2010 19:42:29 +0100
Markus Armbruster <address@hidden> wrote:

> Anthony Liguori <address@hidden> writes:

> > Thanks for the write-up.  Here's my view of how error reporting ought
> > to work:
> >
> > 0) A user tries to do something via some piece of code that serves as
> > the UI.  This may be the -device option handling, the config file
> > parser, QMP, or the human monitor.
> > 1) Something, somewhere, generates an error.  This is may be as
> > primitive as an errno or as sophisticated as a QError object.  In both
> > cases, the error consists of structured data will well defined
> > semantics.
> > 2) That error is propagated up the call chain back to the UI code.
> > 3) The UI code then decides how to present the error to the user.
> 
> This is how QError actually works.  The trouble is that our error
> presentation is too primitive.

 I wouldn't say this is how QError works today because UI can't
decide how to present the error, this becomes an issue if the UI
wants to add context information.

 Now, I agree that error presentation is too primitive and I think
we will have to split this part out of QError in order to fix that.

> > In an ideal world, qdev_device_add would either return a QError object
> > or just an errno.  The caller of qdev_device_add would then decide how
> > to display that error to the user.
> >
> > The whole notion of having a description table baked into QError is
> > wrong IMHO.  You want as much contextual information as possible when
> > generating an error for a user and the place you have that is at the
> > point you're interacting with the user.  It makes no sense to generate
> > error messages deep in the bowels of QEMU.
> 
> Fine in theory, but there are practical problems with lifting all error
> message generation up into UI code.
> 
> Lifting errors means we duplicate them in every UI where they can occur.

 Not if we maintain the description table, so that it can be shared by
UIs for common errors.

[...]

> We may wish to vary the pretty-printing even within a single UI.  For
> instance, in my "Migration already in progress" example,
> QERR_ALREADY_IN_PROGRESS gets pretty-printed specially for command
> "migrate".  Yet a few more places to change.

 One more reason to have the generation of the message in a different
module.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]