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
