Chris Waterson wrote:
> ...including if result parameters can safely be assumed to be left
> untouched in the case of failure; i.e., is this pattern safe?
>
> nsCOMPtr<nsIFoo> foo; // initialized to zero
> bar->GetFoo(getter_AddRefs(foo));
> if (foo) {
> // N.B., if GetFoo() _set_ the out-param and then
> // decided to fail, foo may be non-null, but not a
> // valid nsIFoo pointer.
> }
>
> I'd prefer that this be defined, if possible, to avoid stuff like:
>
> nsCOMPtr<nsIFoo> foo;
> if (NS_SUCCEEDED(bar->GetFoo(getter_AddRefs(foo))) && foo) {
> // Mmm, I'm _so_ paranoid!
> }
I'd be OK with that being defined as well, but I don't believe for a
second that we're going to go back and fix all our method
implementations to only store through the out-param pointers immediately
before returning success.
> Maybe the purists out there will tell me I _always_ have to check the
> return code. I'll politely ask those people to refrain from posting
> whines on n.p.m.performance.
If you're calling through an XPCOM interface, and worried about the
performance implications of a check against 0, you're on crack.
But if the return code indicates that we're out of memory, or some such,
shouldn't you be propagating that failure?
Mike
