Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:46588 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 23321 invoked from network); 31 Dec 2009 13:22:21 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 31 Dec 2009 13:22:21 -0000 Authentication-Results: pb1.pair.com smtp.mail=johannes@php.net; spf=unknown; sender-id=unknown Authentication-Results: pb1.pair.com header.from=johannes@php.net; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 83.243.58.134 as permitted sender) X-PHP-List-Original-Sender: johannes@php.net X-Host-Fingerprint: 83.243.58.134 mailout2.netbeat.de Linux 2.6 Received: from [83.243.58.134] ([83.243.58.134:60310] helo=mailout2.netbeat.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 0F/CE-12956-985AC3B4 for ; Thu, 31 Dec 2009 08:22:20 -0500 Received: (qmail 3706 invoked by uid 89); 31 Dec 2009 13:30:28 -0000 Received: from unknown (HELO ?192.168.1.27?) (postmaster%schlueters.de@93.104.119.175) by mailout2.netbeat.de with ESMTPA; 31 Dec 2009 13:30:28 -0000 X-Originator: 9e51b244e0a38413ab6a9876e36ba9df To: Derick Rethans Cc: Stanislav Malyshev , RQuadling@googlemail.com, Alexey Zakhlestin , PHP Internals In-Reply-To: References: <4B3C4041.6000406@zend.com> <10845a340912310226rdb09b26v12551fab5aedd5ae@mail.gmail.com> <4B3C7E0C.3030907@zend.com> Content-Type: text/plain; charset="UTF-8" Organization: php.net Date: Thu, 31 Dec 2009 14:22:08 +0100 Message-ID: <1262265728.2015.3.camel@guybrush> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] invalid params return value From: johannes@php.net (Johannes =?ISO-8859-1?Q?Schl=FCter?=) On Thu, 2009-12-31 at 12:20 +0000, Derick Rethans wrote: > 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. This is also the documented as the general convention: http://de.php.net/manual/en/functions.internal.php While there are exceptions to this on purpose: For instance get_object is documented to "Return FALSE if /object/ is not an object" (this exception was discussed in detail in the past) johannes