Judson Valeski wrote:
>
> 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."
Good luck on requiring documentation. Yet, I think this is the
only safe thing to do - make rules for the given interface. Even
reading the code to see what it does is not good enough because
code changes. Without a contract you are lost.
I'd discourage people from assuming a success code implies that
the result was not null in cases like this. *Except* for
QueryInterface (where this is the law), this is just a bad
assumption. And, in general, I think people should not be
implementing interfaces that way. In "property getter"-like
methods, null is often a perfectly reasonable value. I think
error codes should only be used to say when something goes wrong
- from the *callee's* point of view.
>
> 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 :-/.
With general conventions you need local exceptions and
documentation of contracts. Are you talking about changing code
to fit the conventions? Or just documenting all the local rules?
What is the priority of such a task as compared with the other
fun stuff everyone is working on?
John.
>
> Jud
