Hi!
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.
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.
It's impossible with or without the change, it's entirely different question.
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
No, exception is not a good thing (that's why I didn't mention it) since a lot of code isn't organized in a way that exceptions can be properly handled, and using exceptions in this case would pretty much lead to using exceptions for any error handling which I don't think PHP community agrees to, and also entirely different topic.
-- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
