2009/12/31 Alexey Zakhlestin <indey...@gmail.com>: > On Thu, Dec 31, 2009 at 7:10 AM, Stanislav Malyshev <s...@zend.com> wrote: >> Hi! >> >> One of the many things that is chaotic in PHP is what internal function >> returns when invalid parameters are given (i.e. params parsing fails). Most >> of those functions do one of: >> >> 1a. just return - this happens with most standard ext code, which was >> converted from old params parsing to a new one. >> 1b. RETURN_NULL() - this is effectively the same as 1a, but the code is >> different. >> >> 2. RETURN_FALSE - some random set of functions does that, e.g. some of PDO >> functions (PDO::prepare, PDO::setAttribute, etc.). NB: I'm not singling out >> PDO here, it happens all over the code, it's just first thing that came to >> my mind. >> >> So, both of the values are kind of OK and both have the same flaw - function >> could legitimately return both NULL and false. I don't have good argument >> for either of these as opposed to another one. However, I think we should >> have ONE standard return value in this case - even better, some macro like >> RETURN_ARGS_FAIL() (if you have a better name, ok). >> >> So, what do you think of that? > > standard macro is a good idea. I also think, that NULL makes more > sense in this case. > NULL kinda means "nothing was returned", which should be the case > exactly (as function didn't start to work, actually) > > > -- > Alexey Zakhlestin > http://www.milkfarmsoft.com/ > Sent from Prague, Czech Republic > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
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). Differentiating between False/Null (something was wrong) and False/Null (the answer to the question you asked is False or Null) is pretty impossible without constantly checking the manual to see what the return values for failure is. The use of error_get_last() would be useful here. I call a function. Something is wrong with my call in some way. I expect Null as a return and have error_get_last() available to explain to me what went wrong. Obviously, the userland code needs to be more defensive in handling these errors. Having a consistent response to ANY call to indicate an error would be extremely useful. The use of set_error_handler() is useful also here, but an inline mechanism may be easier to read. Of course, the question I would next ask (and, oh look, am doing so) is could an exception be thrown? Invalid arguments is a pretty exceptional circumstance. I'd almost say that in the normal course of things, you wouldn't rely on the return value of a function when invalid arguments have been supplied and you wouldn't expect the code to continue. This feels like a true exception. (Hey whadda ya say we talk about an ini option to allow exceptions to be thrown from core for specific errors? ... Nah? ... <grin>). Regards, Richard. -- ----- Richard Quadling "Standing on the shoulders of some very clever giants!" EE : http://www.experts-exchange.com/M_248814.html Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
