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. regards, Derick -- http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org twitter: @derickr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
