2011-06-06 ìí 7:05, Sakari Ailus ì ê:
> On Sat, Jun 04, 2011 at 12:28:04PM +0200, Hans Verkuil wrote:
>> On Friday, June 03, 2011 21:55:10 Laurent Pinchart wrote:
> [clip]
>>>> +{
>>>> + int ret = 0;
>>>> +
>>>> + if (!fh->events)
>>>> + ret = v4l2_event_init(fh);
>>>> + if (!ret)
>>>> + ret = v4l2_event_alloc(fh, n);
>>>> + if (!ret)
>>>> + ret = v4l2_event_subscribe(fh, sub);
>>>
>>> I tend to return errors when they occur instead of continuing to the end of
>>> the function. Handling errors on the spot makes code easier to read in my
>>> opinion, as I expect the main code flow to be the error-free path.
>>
>> Hmmm, I rather like the way the code looks in this particular case. But it;s
>> no big deal and I can change it.
>
> The M5MOLS driver uses this pattern extensively in I2C access error
> handling. I agree with Laurent in principle, but on the other hand I think
> using this pattern makes sense. The error handling takes much less code and
> the test for continuing always is "if (!ret)" it is relatively readable as
> well.
>
> I'm fine with either resolution.
Actually, this pattern was advice from Hans for the M-5MOLS reviews at past,
and it's very helpful and I satisfied mostly.
Also, I was testing or using both this usage and the other one for a while,
and as a result, I figured out which is good choice between continueing to the end
of the function and return imediately, depends on various situation.
Consequently, IMHO, both usgaes are fine, but if the checking factor like (!ret),
changes the other one like (!flag) not ret, then it looks better to return
immediately, or the other handling methods, not using continueing to check error
at the end.
Regards,
Heungjun Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
