Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:46587
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.185 as permitted sender)
Message-ID: <7.0.1.0.2.20091231151339.19f1d818@zend.com>
Date: Thu, 31 Dec 2009 15:21:05 +0200
To: Derick Rethans <derick@php.net>
Cc: Stanislav Malyshev <stas@zend.com>,RQuadling@googlemail.com,
 Alexey Zakhlestin <indeyets@gmail.com>,
 PHP Internals <internals@lists.php.net>
In-Reply-To: <alpine.DEB.2.00.0912311217570.4068@kossu.ez.no>
References: <4B3C4041.6000406@zend.com>
 <cd5680a20912310144p29ed905u63eea7827e97996a@mail.gmail.com>
 <10845a340912310226rdb09b26v12551fab5aedd5ae@mail.gmail.com>
 <4B3C7E0C.3030907@zend.com>
 <alpine.DEB.2.00.0912311217570.4068@kossu.ez.no>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] invalid params return value
From: zeev@zend.com (Zeev Suraski)

At 14:20 31/12/2009, Derick Rethans wrote:
>On Thu, 31 Dec 2009, Stanislav Malyshev wrote:
>
> > > 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.
>
>Hmm, I don't actually think many people test whether parsing parameters
>failed, but they do test the return value. AFAIK, our "standard" is to
>return NULL for parameter parsing failures (at least that's what all the
>examples in README.PARAMETER_PARSING_API do). I'd like to see that be
>the case for all things, but changing it now could be quite a bit of a
>BC break.

I agree.  The real problem is we'd be breaking applications that are 
in fact checking the return values very properly - as properly as 
they can according to the documentation.  Many functions can return 
values that are evaluated as boolean false, well as false/null to 
indicate error;  That results in === being used to check the return 
value, and consequently changing from false to null or vice versa 
would break the code.  Some pedantic users probably use === even if 
the function can't otherwise return a value that evaluates as boolean false.

Zeev