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:
- 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
- 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.
- 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