> I'm trying to come up w/ some trend that will allow for the requirement
> of semantic knowledge about the method to be outside the norm. People
> don't code by looking at the docs (usually non-existant), or digging
> into the impl, of every method call they make.
If you don't know the semantics of the method you're calling, what are
you doing calling it?
> What you're saying is that you *always* have to check both, which I
> think we can (should) narrow down a bit; no? At least w/ attributes that
> only have a single out param.
No, what I'm saying is that you always have to[*] check the result code.
A null value passed back from your method or getter may or may not be
a condition that you, the caller, can cope with. If you need to call a
method on it, then you can't, and should return an error. If you just
need to return it, or check it against another value, for example, then
it's not an error, and you can continue with your business. Null
pointers are often legal values, and it's no more reasonable to make a
sweeping generalizations about the legitimacy of null pointers returned
from a method than it would be to make such generalizations about
PRUint32(0).
[*] We (especially hyatt!) sometimes elide the error checking for
known-infallible methods, but that requires pretty high confidence in
the operation of the method in question, or else pretty high confidence
that the failure can be detected in another way -- perhaps, in fact, by
checking the value of an out param.
Mike
