Chris Waterson wrote:
> > *Check for errors early and often. Every time you make a call into an
> > XPCOM function, you should check for an error condition. You need to
> > do this even if you know that call will never fail.
>
> Okay, I'm gonna draw a line in the sand and claim that this is way too
> facist. Why? Because you know and I know that we over-use COM in an
> obnoxious way. I think that judgement needs to be exercised here.
We indeed overuse COM, but we're still just too loose about how return codes
are used. When I'm reviewing, if I notice someone has dropped an error code,
I assume it's a bug (and I spend cycles digging the callchain to see if the
return value can be legitimately ignored), and then I ask them if they meant
to drop it. If they did mean to drop it, I ask that they stub the return
value w/ "(void)". That makes it explicit that they don't care about the
return code (callback/listener calls often fall into this category). I grow
weary of wading through code, trying to figure out if people meant to drop a
return code or not. When I see a "(void)" stubbing, I know it was
intentional and not an oversight.
My recommendation (I suspect I'm in the minority) for addition to the
doc....
If you don't care about a return value (you better have good reason), stub
the call w/ "(void)" so someone reading the code doesn't think you
inadvertently dropped the return value.
foo->method();
turns into...
(void) foo->method();
I'm not saying ignoring return values is good practice. I side w/ alec on
this one. Check 'em, check 'em, check 'em. But if you drop them, show me it
was intentional (at *least* at the iface level).
Jud
