Le jeu. 30 avr. 2015 à 01:32, Stanislav Malyshev <smalys...@gmail.com> a écrit :
> Hi! > > > The issue targeted here is "two extensions overriding php_error_cb can't > > live side by side" and that issue exists since PHP 4.0. Should a bug > report > > be opened? > > I'm not sure why can't they live side by side. Since you currently can't hook inside php_error_cb, this is the typical sequence while loading 2 extensions that want to extend the error callback mechanism: // Default error handler zend_error_cb = php_error_cb; // Ext 1 zend_error_cb = ext1_error_cb; // Reimplement partially php_error_cb while adding it's own functionality // Ext 2 zend_error_cb = ext2_error_cb; // Reimplement partially php_error_cb while adding it's own functionality Obviously, ext1_error_cb is never called in this scenario. Some workarounds have existed, by copying the original error_cb and calling it additionally, in the above case: ext2_error_cb calling ext1_error_cb because the original pointer was saved, e.g.: ext1_original_error_cb = zend_error_cb; right before overriding zend_error_cb. This leads sometimes to errors being printed twice, because both extensions takes care of printing the error generated. Xdebug, for example, is not calling the original error handler for this reason, producing an HTML table with additional details. > Of course, if the override is made in incompatible manner, they can't, The current problem is that it is not possible at all to make it in a compatible way. In addition to that, extensions' error handlers not calling the original one are forced to copy the original code. > but the same is > true with proposed API - i.e., one extension can boot all other > extension's hooks with zend_clear_error_hook, potentially breaking all > other extension's functionality. > You said it: "potentially" which is a much better situation that "forcibly" :) zend_clear_error_hook is there for completeness. If used, it means you know what you are doing and you forcibly want any previously defined hooks to be removed. One use case being: I don't want any error displaying, let's push mine (or let's have none)! A more complete API would be to propose a function to selectively remove one specific hook, this can still be done using zend_llist_del_element on PG(error_hooks)[E_HOOK_xxx] but we believe we can live without it for now. > > We believe that having an extension that additionally hooks in the error > > handler mechanism (aside Xdebug) would be of a great help to migrate from > > PHP 5.x to 7.0. > > While I agree with the first part, I'm not sure what makes it vital for > 7.0 - as it doesn't introduce BC breaks, is this really important to > have it in major version? Also not sure how it would help migration - if > anything, new API means *more* work when migrating, not less. > We are talking about PHP users migrating to 7.0, not about PHP extension migration. Most PHP developers typically have Xdebug installed and activated, this prevent the use of extensions that collects errors and provide added value (like PECL/APM or commercial tools) to the typical display/logging mechanism of PHP. Note that it doesn't interfere at all with the job of making all PHP extensions compatible with 7. Extensions can still override zend_error_cb like they always did. But at least we can blame the maintainer of not benefiting from the new API and playing nicely with others ;) Cheers, Patrick
