On 24/08/2016 01:29, Nicholas Nethercote wrote:
On Tue, Aug 23, 2016 at 3:22 PM, R Kent James <k...@caspia.com> wrote:
A common programming pattern that I would use, when I don't really care
about why something failed, is:
nsCOMPtr<nsIAsyncInputStream> inputStream;
pipe.GetInputStream(getter_AddRefs(inputStream));
if (!inputStream) {
... take action
}
If I understand the must_use correctly, you are specifically not allowing
that pattern. Why?
It is a common idiom. With a function like that (a getter for a
pointer) you have two ways of detecting failure -- looking at the
return value, or checking if the pointer is null. I prefer looking at
the return value, because:
- Consistency: that's what you do with other nsresult-returning
functions that don't match this idiom.
- Checkability: you can make "check the return value" unforgettable
with MOZ_MUST_USE, as I have done. It's harder to make "check if the
pointer is null" unforgettable. Maybe with a separate static analysis
tool, but that's much less convenient than the compiler telling you
immediately.
Unfortunately, it is sometimes unclear whether "return NS_OK and set
the pointer to null" is a possibility, and also whether "return a
failure code and set the pointer to non-null", which does complicate
things.
Can this problem be solved with more of these types of
annotations/"compiler-aids", that is, could we teach the compiler to
accept either nsresult or out checks at least for simple xpidl property
fetches? Feels like that would avoid some "false" positives and
therefore some rewriting.
I'm mostly in frontend Firefox land so excuse the potentially dumb
question and probably incorrect terminology... My impression was that we
already have things like NonNull, and if we are now forcing nsresult
codes to be actually used, presumably we could just as well indicate
whether particular IDL properties could/couldn't be null, and accept a
check on that rather than the rv if the idiom is very common?
Separately, the "return failure but also set pointer to non-null"
concept sounds very strange to me. Do we have code that actually does
this? For a JS consumer, the return code ends up as an exception, so you
*can't* actually have a js-compatible implementation that both returns a
property value and sets a non-NS_OK return code - the property value
would be unfetchable from JS. With methods (rather than properties) and
outparams, in theory you could, but the resulting consumer code would
look something like:
let baz = {};
try {
foo.maybeGetBaz(baz);
} catch (ex) {
if (baz.value) {
...
}
}
which looks... odd, to say the least.
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
