[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Questionable aspects of QEMU Error's design
From: |
Alex Bennée |
Subject: |
Re: Questionable aspects of QEMU Error's design |
Date: |
Thu, 02 Apr 2020 10:19:23 +0100 |
User-agent: |
mu4e 1.3.10; emacs 28.0.50 |
Daniel P. Berrangé <address@hidden> writes:
> On Thu, Apr 02, 2020 at 07:54:11AM +0200, Markus Armbruster wrote:
>> Peter Maydell <address@hidden> writes:
>>
>> > On Wed, 1 Apr 2020 at 10:03, Markus Armbruster <address@hidden> wrote:
>> >>
>> >> QEMU's Error was patterned after GLib's GError. Differences include:
>> >
>> > From my POV the major problem with Error as we have it today
>> > is that it makes the simple process of writing code like
>> > device realize functions horrifically boilerplate heavy;
>> > for instance this is from hw/arm/armsse.c:
>> >
>> > object_property_set_link(cpuobj, OBJECT(&s->cpu_container[i]),
>> > "memory", &err);
>> > if (err) {
>> > error_propagate(errp, err);
>> > return;
>> > }
>> > object_property_set_link(cpuobj, OBJECT(s), "idau", &err);
>> > if (err) {
>> > error_propagate(errp, err);
>> > return;
>> > }
>> > object_property_set_bool(cpuobj, true, "realized", &err);
>> > if (err) {
>> > error_propagate(errp, err);
>> > return;
>> > }
>> >
>> > 16 lines of code just to set 2 properties on an object
>> > and realize it. It's a lot of boilerplate and as
>> > a result we frequently get it wrong or take shortcuts
>> > (eg forgetting the error-handling entirely, calling
>> > error_propagate just once for a whole sequence of
>> > calls, taking the lazy approach and using err_abort
>> > or err_fatal when we ought really to be propagating
>> > an error, etc). I haven't looked at 'auto propagation'
>> > yet, hopefully it will help?
>>
>> With that, you can have
>>
>> object_property_set_link(cpuobj, OBJECT(&s->cpu_container[i]),
>> "memory", errp);
>> if (*errp) {
>> return;
>> }
>> object_property_set_link(cpuobj, OBJECT(s), "idau", errp);
>> if (*errp) {
>> return;
>> }
>> object_property_set_bool(cpuobj, true, "realized", errp);
>> if (*errp) {
>> return;
>> }
>>
>> but you have to add
>>
>> ERRP_AUTO_PROPAGATE();
>>
>> right at the beginning of the function.
>>
>> It's a small improvement. A bigger one is
>>
>> if (object_property_set_link(cpuobj, OBJECT(&s->cpu_container[i]),
>> "memory", errp)) {
>> return;
>> }
>> if (object_property_set_link(cpuobj, OBJECT(s), "idau", errp)) {
>> return;
>> }
>> if (object_property_set_bool(cpuobj, true, "realized", errp)) {
>> return;
>> }
>>
>> This is item "Return value conventions" in the message you replied to.
>
> Even better, we can then string the checks together
>
> if (object_property_set_link(cpuobj, OBJECT(&s->cpu_container[i]),
> "memory", errp) ||
> object_property_set_link(cpuobj, OBJECT(s), "idau", errp) ||
> object_property_set_bool(cpuobj, true, "realized", errp)) {
> return;
> }
You know at this point I wonder if we can't come up with some data table
that describes all these object interactions and a helper function that
processes it and tells us if it worked or not?
We are essentially just filling out an data structure anyway with all
this stuff.
>
> Regards,
> Daniel
--
Alex Bennée
- Re: Questionable aspects of QEMU Error's design, (continued)
- Re: Questionable aspects of QEMU Error's design, Vladimir Sementsov-Ogievskiy, 2020/04/02
- Re: Questionable aspects of QEMU Error's design, Peter Maydell, 2020/04/02
- Re: Questionable aspects of QEMU Error's design, Daniel P . Berrangé, 2020/04/02
- Re: Questionable aspects of QEMU Error's design, Markus Armbruster, 2020/04/02
- Re: Questionable aspects of QEMU Error's design, Vladimir Sementsov-Ogievskiy, 2020/04/02
- Re: Questionable aspects of QEMU Error's design, Markus Armbruster, 2020/04/02
- Re: Questionable aspects of QEMU Error's design, Vladimir Sementsov-Ogievskiy, 2020/04/02
- Re: Questionable aspects of QEMU Error's design, Markus Armbruster, 2020/04/03
- Re: Questionable aspects of QEMU Error's design, Paolo Bonzini, 2020/04/02
- Re: Questionable aspects of QEMU Error's design, Daniel P . Berrangé, 2020/04/02
- Re: Questionable aspects of QEMU Error's design,
Alex Bennée <=
- Re: Questionable aspects of QEMU Error's design, Eric Blake, 2020/04/02
Re: Questionable aspects of QEMU Error's design, Markus Armbruster, 2020/04/04
Re: Questionable aspects of QEMU Error's design, Markus Armbruster, 2020/04/27