On 5 February 2013 11:50, Ferenc Kovacs <tyr...@gmail.com> wrote: > > Hi, > > We have a note on http://www.php.net/manual/en/functions.internal.php > "Note: If the parameters given to a function are not what it expects, such > as passing an array where a string is expected, the return value of the > function is undefined. In this case it will likely return NULL but this is > just a convention, and cannot be relied upon." > We introduced a new parameter parsing API, which made this behavior more > widely supported: > http://php.net/manual/en/migration53.incompatible.php > "The newer internal parameter parsing API has been applied across all the > extensions bundled with PHP 5.3.x. This parameter parsing API causes > functions to return NULL when passed incompatible parameters. There are some > exceptions to this rule, such as the get_class() function, which will > continue to return FALSE on error." > > I think that the current documentation is lacking in this regard, but I'm > not sure which would be the best solution to address this. >
Whatever happens, we don't want to start adding phrases like "this function will return null and issue an E_WARNING if you feed rubbish into it" to any (nearly all!) functions. Expanding upon that short paragraph mentioned above might be nice, but I would really dislike for us to start "fixing" almost every single function's return types (they would all return "mixed"). I'm sure we've discussed this on-list previously, I'll take a look at the history.
