On 03/06/13 16:19, Kevin Wolf wrote: > Am 06.03.2013 um 16:04 hat Paolo Bonzini geschrieben: >> Il 06/03/2013 15:46, Laszlo Ersek ha scritto: >>>>> We could assert(!error_is_set(errp)) if we wanted. As soon as you've got >>>>> an Error, you must return instead of calling more functions with the >>>>> same error pointer. >>> I think Luiz would suggest (*) to receive any error into a >>> NULL-initialized local_err pointer; do the logic above on local_err, and >>> just before returning, error_propagate() it to errp. >>> >>> (*) I hope you can see what I did there: if you disagree, you get to >>> take that to Luiz, even though he didn't say anything. I'm getting >>> better at working this list! :) >> >> I agree with Laszlo. > > I don't really understand the difference. As long as the function > doesn't depend on the Error object to be present (which it doesn't), > isn't it semantically exactly the same?
The difference is when the caller passes in an already set Error. In this case you release that and replace it with your own error. Usually we stick to the first error encountered. Under the above suggestion you'd keep error handling internal to yourself, and in the end make one attempt to propagate it outwards. If the caller has passed in NULL, the error is dropped. If the caller's passed in a preexistent error, then that one takes precedence and the new one is dropped (but it doesn't interfere with the internal logic). Third, the caller can even accept your error. error_propagate() and error_set() deal with the overwrite attempt differently. The former silently drops the newcomer, whereas the latter assert()s. Of course one wonders why a caller would pass in a preexistent Error. Laszlo
