Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97024
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <3B.50.06670.2F620385@pb1.pair.com>
To: internals@lists.php.net
References: <CAF+90c8Wox0wadAVPsP83er=G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com>
In-Reply-To: <CAF+90c8Wox0wadAVPsP83er=G9jbW__26yBWOFAsjB09rYVFJA@mail.gmail.com>
Date: Sat, 19 Nov 2016 10:18:17 -0000
Lines: 6
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="utf-8";
	reply-type=original
Content-Transfer-Encoding: 7bit
Importance: Normal
Subject: Re: [RFC] Deprecations for PHP 7.2
From: TonyMarston@hotmail.com ("Tony Marston")

"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

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.

-- 
Tony Marston