Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110000
MIME-Version: 1.0
Date: Tue, 5 May 2020 10:42:36 +0200
Message-ID: <CAEPJduk+Mc-1XZNtiztbnn93YsCzqwWoPLO_9rSgPAsSotcVMQ@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c8859105a4e2a166"
Subject: Breaking up php_error_cb/zend_error_cb to improve API for extensions
From: kontakt@beberlei.de (Benjamin Eberlei)

--000000000000c8859105a4e2a166
Content-Type: text/plain; charset="UTF-8"

Heyo,

I am experimenting with changes to break up the central error handling code
into better manageable pieces for a while now. The idea was already voted
positively upon in this RFC
https://wiki.php.net/rfc/improved_error_callback_mechanism by Patrick five
years ago, but it was never implemented at the time.

The end goal should be that no extension should have to overwrite
zend_error_cb anymore, as this is causing heavy side effects between many
extensions. Specifically these three things are causing problems for
everyone involved:

- soap_error_cb hijacking zend_error_cb for rendering errors in SOAP fault
xml
- xdebug not being able to call the original handler
- userland error handlers returning something else than false, which will
skip calls to zend_error_cb entirely

I propose the following things:

1. Provide extensions with a reliable observer API that always gets called,
regardless of error_reporting, display_errors, log_errors, or userland
error callback return value. This fixes problems of many extensions that
interact with the zend_error_cb and interfere with each other (SOAP,
Xdebug, all APM vendors). This API will be triggered **before**
php_error_cb (zend_error_cb) are invoked.

Direct benefit here is that it can also decouple DTrace from zend.c and
some old "report_zend_debug" feature that looks both ancient and entirely
unused.

PR: https://github.com/php/php-src/pull/4555

2. Extract the display logic out of php_error_cb into a pluggable API. The
list of display handlers is iterated and called, until one of the handlers
returns 1 (meaning handled), while others that don't/can't display the
error return 0. This has the goal of allowing extensions to modify how
errors are rendered (Xdebug, SOAP need this).

PR: https://github.com/php/php-src/pull/5484

I started to use this getting rid of soap_error_cb, but the bailout based
exception handling is causing me some headaches. Should be solvable.

3. Extract the logging logic out of php_error_cb /
php_log_err_with_severity into a pluggable API: This could allow extensions
to provide additional logging targets. (No PR yet)

Imho these changes are covered by the existing RFC. But they are going
about it a bit differently than described.

Should I Re-RFC these changes? Otherwise I would go ahead and find a few
reviewers for each of them and merge the changes individually.

greetings
Benjamin

--000000000000c8859105a4e2a166--