Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127935
Precedence: bulk
MIME-Version: 1.0
References: <hzKdzBWWITU1ePjv3qcyK-OzroFAkWst9MQBw2zvKSA8pk1iqruLZZWTTh9gYDo2QX8EY_PiirVYDuwne2Upr3GlqZk570wtLOF49aaP-HQ=@gpb.moe>
 <eb03c51b-344f-4d6d-9e73-7e499b43a928@gmail.com> <AM8P250MB017056034C85B7785F5A7AB8E24CA@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
In-Reply-To: <AM8P250MB017056034C85B7785F5A7AB8E24CA@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
Reply-To: erictnorris@gmail.com
Date: Mon, 7 Jul 2025 11:46:25 -0400
Message-ID: <CA+NMNO0wC4iLTtED9y6jWL2XkSrTH8aZ5Kd9f7arT_XA3+Lktw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.5
To: Bob Weinand <bobwei9@hotmail.com>
Cc: "Gina P. Banyard" <internals@gpb.moe>, Niels Dossche <dossche.niels@gmail.com>, internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
From: eric.t.norris@gmail.com (Eric Norris)

> ** Deprecate the error_prepend_string and error_append_string INI directives
>    Why is that of questionable use? Why is "this is a development and debugging feature" considered a valid reason to get rid of something? It allows prominently displaying issues in development when they would be hidden behind other HTML otherwise.

I recently made a change to the php_error_cb function for the Error
Backtraces v2 RFC (https://wiki.php.net/rfc/error_backtraces_v2), and
I recall that working inside that function was quite difficult. The
error_prepend_string and error_append_string directives are a tiny
part of the complexity there, but nonetheless removing them would
maybe start to move us in a direction of greatly simplifying the
implementation of php_error_cb, which I would support. I don't have
strong feelings here, however.