Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66717
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <A225D9BBF238624AB8DB155CC6466CCA0B56018D@VEXCHANGE10.zoo.lan>
References: <A225D9BBF238624AB8DB155CC6466CCA0B56018D@VEXCHANGE10.zoo.lan>
Date: Wed, 20 Mar 2013 17:14:03 +0100
Message-ID: <CAH-PCH7dwq9au1jkZFM5DpXQjR4JmNndbiCaz9dtWHR9tGd2Xg@mail.gmail.com>
To: Richard Bradley <Richard.Bradley@softwire.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=90e6ba6e8f30bbaab404d85d82fc
Subject: Re: [PHP-DEV] E_RECOVERABLE_ERROR for "Call to a member function on a non-object"
From: tyra3l@gmail.com (Ferenc Kovacs)

--90e6ba6e8f30bbaab404d85d82fc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 20, 2013 at 3:37 PM, Richard Bradley <
Richard.Bradley@softwire.com> wrote:

> I'd like to patch PHP to make "Call to a member function on a non-object"
> an 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
> Function on Non-Object Should Throw An Exception
> *         #46601<https://bugs.php.net/bug.php?id=3D46601>
> E_RECOVERABLE_ERROR for "Call to a member function on a non-object"
> *         #51848<https://bugs.php.net/bug.php?id=3D51848> Non-object meth=
od
> call errors should be catchable with set_error_handler()
> *         #63538<https://bugs.php.net/bug.php?id=3D63538> "Call to
> undefined function" should be catchable
>
> I have read
> https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process
>
> 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-compatibility grounds?
>
> 3.       If I put the effort in to create the RFC and a patch, would it b=
e
> likely to be accepted?
>
> 4.       Has anyone attempted this change before and had it rejected, or
> given 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.
> Your test suite will not be able to continue at the next test, and all
> further 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
> button");
>                 }
>                 $button->click()
>
> However, this is laborious and easy to overlook. The consequences of
> forgetting this manual null check seem disproportionately and unnecessari=
ly
> severe.
>
> It would be more convenient if the null dereference was an
> E_RECOVERABLE_ERROR, 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.constants.php says that these errors
> are "Fatal run-time errors. These indicate errors that can not be recover=
ed
> from, such as a memory allocation problem. Execution 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 capable of continuing if the user's script requests it.
> This error is a much better match for the description of
> E_RECOVERABLE_ERROR from the same page: "a probably dangerous error
> occurred, but did not leave the Engine in an unstable state"
>
> See also
> http://stackoverflow.com/questions/15502559/php-turn-call-to-a-member-fun=
ction-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
> Studios, 53-79 Highgate Road, London NW5 1TL
> Softwire Technology Limited. Registered in England no. 3824658. Registere=
d
> Office : 13 Station Road, London N3 2SB
>

1, yes
2, yes
3, depends on the patch
4, yes, at least there were a couple of discussions in general about
removing/converting some of the fatals to recoverable fatas

In general there are cases where the cause of the error isn't a fatal one,
but it would leave the engine in a half-baked state and usually it is
easier to fatal out than implement a proper state recover/reset so that the
whole thing won't blow up to your face at the next execution step.

ps: there were also https://bugs.php.net/bug.php?id=3D54195&edit=3D2

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--90e6ba6e8f30bbaab404d85d82fc--