This issue has come up several times in the past few days, as well as in
several postings on this newsgroup. I'd like to try and consolodate and
come up w/ a consistent trend we can follow.
The problem: There is no standard (if there is it's not followed) for
how to handle return values *and* out/params.
Take this method definition:
void foo(out string aString);
Should checking the return value be enough to protect me from a null
aString being returned? For example: is this enough?
char *myString;
nsresult rv = foo(&myString);
if (NS_SUCCEEDED(rv)) {
myString[0]; // am I guaranteed that myString is valid?
}
or do I need to do...
char *myString;
nsresult rv = foo(&myString);
if (NS_SUCCEEDED(rv)) {
if (myString) {
myString[0];
}
}
I see code all over the place that just ignores the nsresult, and checks
for a null out param (in our unwieldy world, that's indeed the "safest"
thing to do). I also see a lot of the "double-checking" which is a waste.
IMO, Get*() methods (including attributes), should return
NS_ERROR_FAILURE if they can't give you *something* (other than null)
back. I also suggest that *if* a null out param is valid (meaning you
may indeed get null back in the out param, even if the method returns
something NS_SUCCEEDED() likes), it must be documented. I'm basically
looking for some nice little statement that can be made about usage.
I like "out params should *not* be checked for null unless documentation
specifies otherwise. if an attribute getter returns NS_OK (or other
success codes), you are guaranteed to have a valid (non-null) out param."
I think we should come up w/ something so people can stop bullet
proofing their method calls to handle failed return codes *and* null out
params. maybe the faith in method calls is gone and this is a lost cause
anyway :-/.
Jud
