Mike Shaver wrote:
> > * Need to explicitly define the possible return codes from *all*
> > methods. which ones can return NS_OK and nsnull... Remember,
> > NS_ERROR_FAILURE causes an exception to be thrown in Javascript !!
>
> None of our standardized interfaces should have methods that return
> things other than nsresults, so we should probably reword that to
> something like
>
> Need to explicitly list result codes and out-parameter states.
...including if result parameters can safely be assumed to be left
untouched in the case of failure; i.e., is this pattern safe?
nsCOMPtr<nsIFoo> foo; // initialized to zero
bar->GetFoo(getter_AddRefs(foo));
if (foo) {
// N.B., if GetFoo() _set_ the out-param and then
// decided to fail, foo may be non-null, but not a
// valid nsIFoo pointer.
}
I'd prefer that this be defined, if possible, to avoid stuff like:
nsCOMPtr<nsIFoo> foo;
if (NS_SUCCEEDED(bar->GetFoo(getter_AddRefs(foo))) && foo) {
// Mmm, I'm _so_ paranoid!
}
Maybe the purists out there will tell me I _always_ have to check the
return code. I'll politely ask those people to refrain from posting
whines on n.p.m.performance.
chris
