Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97028
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <3B.50.06670.2F620385@pb1.pair.com>
References: <CAF+90c8Wox0wadAVPsP83er=G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com>
 <3B.50.06670.2F620385@pb1.pair.com>
Date: Sat, 19 Nov 2016 12:20:55 +0100
Message-ID: <CAF+90c91SPFOHiTJGpwTEvZt_Wyk+hTX4-TANTMsshhcTQQVfw@mail.gmail.com>
To: Tony Marston <TonyMarston@hotmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c07709ac9e2930541a59dbf
Subject: Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.2
From: nikita.ppv@gmail.com (Nikita Popov)

--94eb2c07709ac9e2930541a59dbf
Content-Type: text/plain; charset=UTF-8

On Sat, Nov 19, 2016 at 11:18 AM, Tony Marston <TonyMarston@hotmail.com>
wrote:

> "Nikita Popov"  wrote in message news:CAF+90c8Wox0wadAVPsP83er=
> G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com...
>
>
>> Hi internals!
>>
>> I've submitted this RFC for PHP 7.1 previously, but didn't follow through
>> due to time constraints. Now I'd like to propose an extended version for
>> PHP 7.2 and vote on it sooner rather than later to avoid a repeat
>> performance.
>>
>>    https://wiki.php.net/rfc/deprecations_php_7_2
>>
>> The RFC combines a number of deprecation and removal proposals. Each one
>> will get a separate 2/3 majority vote. The RFC overlaps with some recently
>> discussed topics (each, binary strings) -- I'm fine with dropping these if
>> someone has a more specific RFC.
>>
>> I expect some of these are no-brainers, while others are more
>> controversial
>> -- please share your specific concerns.
>>
>> Thanks,
>> Nikita
>>
>
> I am against the removal of the $errorcontext argument of error handler as
> this has been a valuable part of my error handler for over ten years.
> Whenever trigger_error() is called with a fatal error I write all available
> details to a log file as well as sending an email. In order to obtain
> additional data I use errorcontext to determine the following:
>
> a) Was it called from a function or an object? For this I use code such as
> the following:
>
> if (isset($errcontext['this']) AND is_object($errcontext['this'])) {
>
> b) If it was called from an object, was it one of my database objects? If
> yes, then obtain some extra information using code such as the following:
>
>        // retrieve error details from DML object
>        if (method_exists($errcontext['this'], 'getQuery')) {
>            $query  = $errcontext['this']->getQuery();
>        } // if
>        if (method_exists($errcontext['this'], 'getErrorNo')) {
>            $errno  = $errcontext['this']->getErrorNo();
>        } // if
>        if (method_exists($errcontext['this'], 'getErrorString')) {
>            $errstr = $errcontext['this']->getErrorString();
>        } // if
>        if (method_exists($errcontext['this'], 'getErrorString2')) {
>            $errstr2 = $errcontext['this']->getErrorString2();
>        } // if
>

I'm afraid you're out of luck here :/ This usage will no longer be possible
as of PHP 7.1 -- independently of the deprecation proposed in this RFC.
See: https://3v4l.org/sQBL9

Prior to PHP 7.1 $this was *sometimes* included in the symbol table (to be
more precise, whenever $this was used as a CV, rather than implicit UNUSED
operand). As of PHP 7.1 $this is never included in the symbol table. This
change is due to https://wiki.php.net/rfc/this_var.

But! This functionality is still available through debug_backtrace().
That's the correct way of fetching the $this of a parent frame, which
should always work (rather than *sometimes* on PHP < 7.1), and is
independent of the error handling mechanism.

So, to clarify: Is $this the only thing from the error context you're
interested in? Or do you also use all the other variables?


> Saying that I should stop using $errorcontext and instead use a debugger
> is very short sighted. I *NEED* to have this data available in the error
> log as soon as the error happens. In several cases I cannot use a debugger
> as my application is running behind a client's firewall and their security
> restrictions forbid the use of a debugger from outside of that firewall.


> I notice that the reason for this recommendation is "because the
> $errcontext can be used to modify all references and objects in the current
> scope." If this is the case then why not make $errorcontext read-only so
> that nothing can be changed. I can imagine lots of people reading from
> $errorcontext, but how many actually write? I certainly don't.


We can do this for references (i.e., dereference them for the provided
symbol table), but not for objects, because we don't have any way of
enforcing immutability on the language side.

Thanks,
Nikita

--94eb2c07709ac9e2930541a59dbf--