Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:46586 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 17987 invoked from network); 31 Dec 2009 12:20:50 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 Dec 2009 12:20:50 -0000 Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender) X-PHP-List-Original-Sender: derick@php.net X-Host-Fingerprint: 82.113.146.227 xdebug.org Linux 2.6 Received: from [82.113.146.227] ([82.113.146.227:47334] helo=xdebug.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D4/0E-12956-F179C3B4 for ; Thu, 31 Dec 2009 07:20:49 -0500 Received: from localhost (xdebug.org [127.0.0.1]) by xdebug.org (Postfix) with ESMTPS id A126FDE001; Thu, 31 Dec 2009 12:20:44 +0000 (UTC) Date: Thu, 31 Dec 2009 12:20:44 +0000 (GMT) X-X-Sender: derick@kossu.ez.no To: Stanislav Malyshev cc: RQuadling@googlemail.com, Alexey Zakhlestin , PHP Internals In-Reply-To: <4B3C7E0C.3030907@zend.com> Message-ID: References: <4B3C4041.6000406@zend.com> <10845a340912310226rdb09b26v12551fab5aedd5ae@mail.gmail.com> <4B3C7E0C.3030907@zend.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: [PHP-DEV] invalid params return value From: derick@php.net (Derick Rethans) 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. regards, Derick -- http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org twitter: @derickr