503619 - Add+enforce NS_ALWAYS_OK attribute

Status: RESOLVED INACTIVE

(Developer Infrastructure :: Source Code Analysis, defect)

Description

[(dormant account)]

Xpcom forces us to use nsresults for methods that never fail. 
This then suggests to defensive programmers that they should check for errors.
Code ends up with lots of pointless NS_FAILED spaghetti.

This would also have a side benefit of flagging methods for outparamdelling if we decide to break source comparability.

The way to do this is to add a flag to idl that a class may not be implemented in JS and then statically check that the methods do indeed only return NS_OK.

Comment 1

[Brendan Eich [:brendan]]

We should deCOMtaminate. Any XPCOM interface that's scriptable, where the method is scriptable, could be implemented fallibly by JS, even if its C++ impl is not fallible. So we can't always be sure something will be "always OK".

But in the case where we can be sure, then it must be a non-scriptable API, so ripe for deCOMtamination, right?

/be

Comment 2

[(dormant account)]

(In reply to comment #1)
> We should deCOMtaminate. Any XPCOM interface that's scriptable, where the
> method is scriptable, could be implemented fallibly by JS, even if its C++ impl
> is not fallible. So we can't always be sure something will be "always OK".
> 
> But in the case where we can be sure, then it must be a non-scriptable API, so
> ripe for deCOMtamination, right?

 I meant this for things like nsIFile::GetNativeLeafName, etc. Stuff that can get called from JS and is likely to be used in non-mozilla code. I agree that we should decomtaminate in the long term, but this would be a good nearterm step.