[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] chardev's and fd's in monitors
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] chardev's and fd's in monitors |
Date: |
Thu, 20 Oct 2016 12:10:52 +0100 |
User-agent: |
Mutt/1.7.0 (2016-08-17) |
On Thu, Oct 20, 2016 at 12:01:08PM +0100, Dr. David Alan Gilbert wrote:
> * Markus Armbruster (address@hidden) wrote:
> > "Dr. David Alan Gilbert" <address@hidden> writes:
>
> > > The problem is that our way of propagating errors actively discourages
> > > people from adding errors and you're left with lots of useless invented
> > > errno's.
> > > error_report makes it easy for people to scatter meaningful error messages
> > > in at any point.
> > >
> > > Make an easy, concise way of reporting an error that fits in with
> > > a propagation scheme and I'd consider converting stuff.
> >
> > error_setg(errp, "This is as simple as it gets, I'm afraid")
> >
> > Snark aside, I acknowledge the pain of converting call chains to
> > propagate Error objects, having converted "a few" myself.
>
> If you can get it down to that line it would be great!
>
> But unfortunately it isn't:
> a) I have to make sure my cleanup path after that error_setg doesn't
> cause any other errors because that breaks the rule
> that I can't call error_setg twice.
> b) I've got to put the whole local_err/error_propagate stuff all over.
>
> c) We insist on allowing the Err ** pointer to be NULL that
> removes some potential simplifications.
This last point is one i really dislike - if we could mandate that
the error parameters was non-NULL, it will eliminate alot of the
need to use local_err/error_propagate, as you could just check
if (*errp), and so largely solve (b).
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
- Re: [Qemu-devel] chardev's and fd's in monitors, (continued)
- Re: [Qemu-devel] chardev's and fd's in monitors, Dr. David Alan Gilbert, 2016/10/20
- Re: [Qemu-devel] chardev's and fd's in monitors, Markus Armbruster, 2016/10/20
- Re: [Qemu-devel] chardev's and fd's in monitors, Daniel P. Berrange, 2016/10/20
- Re: [Qemu-devel] chardev's and fd's in monitors, Dr. David Alan Gilbert, 2016/10/20
- Re: [Qemu-devel] chardev's and fd's in monitors, Markus Armbruster, 2016/10/20
- Re: [Qemu-devel] chardev's and fd's in monitors, Dr. David Alan Gilbert, 2016/10/20
- Re: [Qemu-devel] chardev's and fd's in monitors,
Daniel P. Berrange <=
- Re: [Qemu-devel] chardev's and fd's in monitors, Markus Armbruster, 2016/10/20
- Re: [Qemu-devel] chardev's and fd's in monitors, Daniel P. Berrange, 2016/10/20
- Re: [Qemu-devel] chardev's and fd's in monitors, Markus Armbruster, 2016/10/20
- Re: [Qemu-devel] chardev's and fd's in monitors, Dr. David Alan Gilbert, 2016/10/20
- Re: [Qemu-devel] chardev's and fd's in monitors, Markus Armbruster, 2016/10/21
- Re: [Qemu-devel] chardev's and fd's in monitors, Daniel P. Berrange, 2016/10/21
- Re: [Qemu-devel] chardev's and fd's in monitors, Dr. David Alan Gilbert, 2016/10/21
- Re: [Qemu-devel] chardev's and fd's in monitors, Dr. David Alan Gilbert, 2016/10/21
- Re: [Qemu-devel] chardev's and fd's in monitors, Paolo Bonzini, 2016/10/19
- Re: [Qemu-devel] chardev's and fd's in monitors, Dr. David Alan Gilbert, 2016/10/19