Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66716
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain softwire.com does not designate 195.130.217.76 as permitted sender)
To: "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: E_RECOVERABLE_ERROR for "Call to a member function on a
 non-object"
Thread-Index: Ac4lYzeJeXfmE9xyRxSB4gCmzYhkAA==
Date: Wed, 20 Mar 2013 14:37:51 +0000
Message-ID: <A225D9BBF238624AB8DB155CC6466CCA0B56018D@VEXCHANGE10.zoo.lan>
Accept-Language: en-GB, en-US
Content-Language: en-US
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="_000_A225D9BBF238624AB8DB155CC6466CCA0B56018DVEXCHANGE10zool_"
Subject: E_RECOVERABLE_ERROR for "Call to a member function on a non-object"
From: Richard.Bradley@softwire.com (Richard Bradley)

--_000_A225D9BBF238624AB8DB155CC6466CCA0B56018DVEXCHANGE10zool_
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable

I'd like to patch PHP to make "Call to a member function on a non-object" a=
n E_RECOVERABLE_ERROR instead of an E_ERROR.

I have not been able to find any previous discussion of making this change,=
 but there are several PHP bugs requesting it:
*         #51882<https://bugs.php.net/bug.php?id=3D51882> Call To Member Fu=
nction on Non-Object Should Throw An Exception
*         #46601<https://bugs.php.net/bug.php?id=3D46601> E_RECOVERABLE_ERR=
OR for "Call to a member function on a non-object"
*         #51848<https://bugs.php.net/bug.php?id=3D51848> Non-object method=
 call errors should be catchable with set_error_handler()
*         #63538<https://bugs.php.net/bug.php?id=3D63538> "Call to undefine=
d function" should be catchable

I have read https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_proc=
ess

I would like to know:

1.       Do I need to create an RFC for this change, or could I just create=
 a pull request in GitHub?

2.       Would anyone object to this change? For example on backwards-compa=
tibility grounds?

3.       If I put the effort in to create the RFC and a patch, would it be =
likely to be accepted?

4.       Has anyone attempted this change before and had it rejected, or gi=
ven up?

Technical summary:

If you make a member function call on a null value (or any other non-object=
), a fatal error is raised. This makes it completely impossible to recover =
from null-ref errors.
For example, in a Behat test suite, you might write:
                $session->getPage()->find('css', '#next')->click()

If the "find" function returns NULL, then the "->click()" call is fatal. Yo=
ur test suite will not be able to continue at the next test, and all furthe=
r output will be lost.

The simple workaround is to check the value before invoking a function, i.e=
.:
                $button =3D $session->getPage()->find('css', '#next');
                if (empty($button)) {
                                throw new Exception("Could not find #next b=
utton");
                }
                $button->click()

However, this is laborious and easy to overlook. The consequences of forget=
ting this manual null check seem disproportionately and unnecessarily sever=
e.

It would be more convenient if the null dereference was an E_RECOVERABLE_ER=
ROR, which would allow scripts to convert the error into an exception, and =
continue the script at the next suitable point, via a "catch".

The documentation for E_ERROR at http://php.net/manual/en/errorfunc.constan=
ts.php says that these errors are "Fatal run-time errors. These indicate er=
rors that can not be recovered from, such as a memory allocation problem. E=
xecution of the script is halted."

It doesn't seem to me that dereferencing "null" with "->" would be an error=
 that "can not be recovered from, such as a memory allocation problem". In =
fact, the interpreter should be in a very predictable state, and quite capa=
ble of continuing if the user's script requests it.
This error is a much better match for the description of E_RECOVERABLE_ERRO=
R from the same page: "a probably dangerous error occurred, but did not lea=
ve the Engine in an unstable state"

See also http://stackoverflow.com/questions/15502559/php-turn-call-to-a-mem=
ber-function-on-a-non-object-into-exception

Thanks for your time,


Rich




Richard Bradley
Tel : 020 7485 7500 ext 3230 | Fax : 020 7485 7575

softw i re
Sunday Times Best Small Companies 2012 - 6th in the UK
Web : www.softwire.com<http://www.softwire.com/> | Addr : 325 Highgate Stud=
ios, 53-79 Highgate Road, London NW5 1TL
Softwire Technology Limited. Registered in England no. 3824658. Registered =
Office : 13 Station Road, London N3 2SB

--_000_A225D9BBF238624AB8DB155CC6466CCA0B56018DVEXCHANGE10zool_--