Re: Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object
get_class_error_001.phpt get_class_variation_001.phpt

From: Date: Mon, 16 Mar 2009 17:59:41 +0000
Subject: Re: Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object
get_class_error_001.phpt get_class_variation_001.phpt
References: 1 2 3 4 5 6 7  Groups: php.internals 
Request: Send a blank email to internals+get-43370@lists.php.net to get a copy of this message
On Mon, Mar 16, 2009 at 6:49 PM, Stanislav Malyshev <stas@zend.com> wrote: > Hi! > >> The new parsing API and the strictness of this "return NULL" rule is >> new and arguable. As it is not that important (work 'round is easy), I >> tend to prefer to minimize the wtf instead of being too strict. > > Minimizing the WTF may also mean standardizing exception handling - i.e. > knowing what functions actually return when something's wrong without having > to consult the manual each time. First it is not an exception. Secondly, as I said earlier already, this rule is arguable, even more in this particular case. Return NULL when an argument is missing could be fine but to return NULL when an argument cannot be processed is not necessary a good idea. For example: <?php var_dump(is_int($b); ?>, do we want NULL here? Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org

« previous php.internals (#43370) next »