Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77001
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.207 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-ID: <E4EDB8A3-20DD-4DB9-AEB8-581B42222628@ajf.me>
Date: Sun, 31 Aug 2014 23:01:39 +0100
To: PHP Internals <internals@lists.php.net>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Make zend_parse_parameters emit E_RECOVERABLE_ERROR
From: ajf@ajf.me (Andrea Faulds)

Good evening,

Here=92s a suggestion: Why don=92t we make zend_parse_parameters emit
E_RECOVERABLE_ERROR on failure, rather than just emitting E_WARNING and
returning FAILURE (causing the caller to typically bail out and return =
NULL)?
This would bring it into line with userland type hints, which also cause =
such
errors. It might also cause errors to be caught sooner, as just =
returning NULL
can cause cryptic problems down the line. It=92s worth noting that
zend_parse_parameters is very tolerant in terms of what parameters you =
can pass
it and is unlikely to error unless you do something really weird such as
passing an array to strlen(). I doubt this would affect backwards =
compatibility
much, unless your application relies on a silenced warning (which is =
possible,
but discouraged behaviour), and it=92s the type of BC break that would =
be really
obvious (your application errors and stops execution).

Thoughts?
--
Andrea Faulds
http://ajf.me/