Il 05/12/2013 16:32, Igor Mammedov ha scritto: >>> > > * make Error* mandatory for all void functions > one more advantage: > + not need to pepper every property setter/getter with local_error + > error_propagate(), > i.e. reduced code duplication.
Note that for something like tail calls there is no need for error_propagate. See get_enum/set_enum (and a lot more examples) in hw/core/qdev-properties.c. With your proposal, this: visit_type_bool(v, &value, name, &local_err); if (local_err) { error_propagate(errp, local_err); return; } bit_prop_set(dev, prop, value); could indeed become visit_type_bool(v, &value, name, errp); bit_prop_set(dev, prop, value); because both caller and callee return void. This is because both the caller (prop_set_bit) and callee (visit_type_bool) are void. But here come the next point: >>> > > + consistent >>> > > + almost predictable (because in C you can ignore return values) > there is no return values from void functions. You can ignore return values from int-returning functions. So if I see func(..., NULL); func(..., errp); it's not clear if it aborts on error, or just eats the error. > > - requires manual effort to abide to the policy > with assert inside API there is no manual effort. But as Marcus > noted these errors will be only runtime detectable :( I referred to manual effort of adding assertions in leaf functions. Just one missing assertion can be very problematic if non-leafs start relying on this behavior. I think Error is hard to misuse if you don't mind being verbose. This proposal would cut the verbosity (not sure how much, but it definitely could) but it would be easier to misuse. In terms of Rusty's API design manifesto (http://sweng.the-davies.net/Home/rustys-api-design-manifesto) your proposal would move the API from 4 to 3 or 2: 4. Follow common convention and you'll get it right. 3. Read the documentation and you'll get it right. 2. Read the implementation and you'll get it right. Paolo