Re: invalid params return value

At 14:20 31/12/2009, Derick Rethans wrote:

On Thu, 31 Dec 2009, Stanislav Malyshev wrote:

Would changing the returning value to Null to indicate invalid arguments (or any other error condition) would create a significant BC surely? Just how many functions are documented with the entity &return.falseforfailure;? (198 files using this so far vs Return &null; which is used very rarely).

There are different kinds of failure. There's failure for the function (i.e. function tried to do something and failed, like couldn't open the file) and failure where function wheren't even executed (like you called fopen without giving it a filename). Some functions return the same in both cases, some do not. I'm sure half of the functions documented as &return.falseforfailure; return NULL on incorrect args. As for BC - it may break some scripts that don't check properly but having each function do different thing is worse, since you couldn't even write a proper check - since you have no way of knowing what to check for. Hmm, I don't actually think many people test whether parsing parameters failed, but they do test the return value. AFAIK, our "standard" is to return NULL for parameter parsing failures (at least that's what all the examples in README.PARAMETER_PARSING_API do). I'd like to see that be the case for all things, but changing it now could be quite a bit of a BC break.

I agree. The real problem is we'd be breaking applications that are in fact checking the return values very properly - as properly as they can according to the documentation. Many functions can return values that are evaluated as boolean false, well as false/null to indicate error; That results in === being used to check the return value, and consequently changing from false to null or vice versa would break the code. Some pedantic users probably use === even if the function can't otherwise return a value that evaluates as boolean false. Zeev