Mike Shaver wrote:
> Judson Valeski wrote:
>
>> Should checking the return value be enough to protect me from a null
>> aString being returned?
>
> No. They're semantically quite different, and describe different
> conditions. The result code will tell you about the operation of the
> method, which might fail for a whole number of reasons. It's up to
> the caller to decide, based on the semantics of the method being
> called, whether it considers a null out param to be an error.
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.
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.
Jud
