Hi Johannes,
Johannes Schlüter wrote:
Hi,
On Mon, 2009-03-16 at 09:52 +0000, "Dmitry Stogov" wrote:
Log:
Fixed bug #47664 (get_class returns NULL instead of FALSE)
[...]
@@ -716,7 +716,7 @@
int dup;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|o",
&obj) == FAILURE) {
- return;
+ RETURN_FALSE;
}
Usually we return NULL in case parameter parsing fails, this is
documented like this:
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.
http://www.php.net/manual/en/functions.internal.php
>
This also applies to many other functions which usually return "false"
on error and are documented like that. Therefore I think returning NULL
in this case is a good thing in order to bring more consistency to the
language and I think this BC break is quite minor.
I don't think changing of documented behaviour in minor version makes
sense. And I don't see a lot of consistency in returning NULL in case
each function documentation doesn't say it.
Really, I would prefer special kind of exception.
Thanks. Dmitry.
On a sidenote: There are cases where such a change has bigger effect: In
all cases where int(0)/string("") are "successful" return values and one
has to use type-safe comparison (think about strpos for instance) but in
this case I see more of a cleanup. Oh and the user should, usually,
check the types before passing the variable to the function ...
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
