On 8/24/16 7:38 AM, Gijs Kruitbosch wrote:
Separately, the "return failure but also set pointer to non-null"
concept sounds very strange to me.
There are two possible ways of thinking about outparams in XPCOM:
1) The callee must not touch the outparam values when returning an error
result.
2) The caller must not examine the outparam values when an error result
was returned.
We haven't been very consistent about which convention we use,
unfortunately. I _think_ at one point #1 was the intended convention,
but we certainly have callees that violate it by, for example,
0-initializing all outparams up front to make it simpler to have
multiple success return points...
In practice, there are various code patterns that _can_ result in
"return failure but set to non-null". Here's a simple example:
nsresult
Foo::GetBar(nsIBar** aBar)
{
nsresult rv = SomeFactorMethod(aBar);
NS_ENSURE_SUCCESS(rv);
return (*aBar)->Init();
}
Now I agree that in this case it would be better to not write to *aBar
until we know Init() succeeds. That doesn't mean all of our code does
that. :(
Do we have code that actually does this?
Hopefully not, but I can't guarantee it.
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
Oh, I don't think anyone does this on _purpose_.
-Boris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
