rfc:improved_error_callback_mechanism

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:improved_error_callback_mechanism [2015/03/16 09:53] – oliviergarciarfc:improved_error_callback_mechanism [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 1: Line 1:
 ====== PHP RFC: Improved Error Callback Mechanism ====== ====== PHP RFC: Improved Error Callback Mechanism ======
-  * Version: 0.1+  * Version: 0.4
   * Create Date: 2015-03-13   * Create Date: 2015-03-13
-  * Modify Date: 2015-03-13+  * Modify Date: 2015-06-10
   * Author: Patrick Allaert <patrick@catchy.io>, Olivier Garcia <olivier@catchy.io>   * Author: Patrick Allaert <patrick@catchy.io>, Olivier Garcia <olivier@catchy.io>
-  * Status: Under discussion+  * Status: Abandoned
   * First Published at: http://wiki.php.net/rfc/improved_error_callback_mechanism   * First Published at: http://wiki.php.net/rfc/improved_error_callback_mechanism
  
Line 22: Line 22:
 ===== Proposal ===== ===== Proposal =====
  
-We propose to split ''php_error_cb'' into multiple hookable parts corresponding to the following behaviours: +We propose to split ''php_error_cb'' into multiple hookable categories corresponding to the following behaviours: 
-  - Display the error (**display** part) +  - Display the error (**display** category) 
-  - Log the error (**log** part) +  - Log the error (**log** category) 
-  - Do additional processing if needed (**process** part), empty by default +  - Do additional processing if needed (**process** category), empty by default 
-  - Check if the error is recoverable and bail out if needed (**bailout** part)+  - Check if the error is recoverable and bail out if needed (**bailout** category)
  
-We believe that there is no interesting use case for hooking the other existing parts of ''php_error_cb''.+We believe that there is no interesting use case for hooking the other existing categories of ''php_error_cb''.
  
-An extension that want to **extend** one of the part can do it so with:+An extension that want to extend one of the category can do it so by **appending** a hook:
 <code c> <code c>
-    PHP_ERROR_HOOK_API my_logging_hook(PHP_ERROR_HOOK_ARGS) {+    ZEND_ERROR_CB_API my_logging_hook(ZEND_ERROR_CB_HOOK_ARGS)
         /* Do some logging with error line number, filename, message, ... */         /* Do some logging with error line number, filename, message, ... */
     }     }
  
-    zend_add_error_hook(E_HOOK_LOG, my_logging_hook);+    zend_append_error_hook(E_HOOK_LOG, my_logging_hook);
 </code> </code>
  
-An extension that want to **clear** one of the part can do it so with:+Each hook must return either ''SUCCESS'' or ''FAILURE'' : if ''FAILURE'' is returned, the next hooks of current category won't be called. 
 + 
 +**Prepending** is also possible in the case one want to execute a hook before the others of the same category: 
 +<code c> 
 +    zend_prepend_error_hook(E_HOOK_LOG, my_logging_hook); 
 +</code> 
 + 
 +An extension that want to **clear** all hooks from a specific category can do it so with:
 <code c> <code c>
     zend_clear_error_hook(E_HOOK_DISPLAY);     zend_clear_error_hook(E_HOOK_DISPLAY);
 </code> </code>
  
 +''zend_append_error_hook'', ''zend_prepend_error_hook'' and ''zend_clear_error_hook'' will operate on one of the internal linked lists of error hooks. There will be one linked list for each category, referred to with one of the constants: ''E_HOOK_DISPLAY'', ''E_HOOK_LOG'', ''E_HOOK_PROCESS'' or ''E_HOOK_BAILOUT''. Those linked lists will, by default, contain the original implementation.
  
-''zend_add_error_hook'' and ''zend_clear_error_hook'' will operate on one of the internal linked lists of error hooks. There will be one linked list for each parts, referred to with one of the constants: ''E_HOOK_DISPLAY'', ''E_HOOK_LOG'', ''E_HOOK_PROCESS'' or ''E_HOOK_BAILOUT''. Those linked lists will, by default, contain the original implementation.+The modification of hook lists must be done during the MINIT phase.
  
 ==== Overview of the improved ''php_error_cb'' ==== ==== Overview of the improved ''php_error_cb'' ====
Line 63: Line 71:
         /** calling E_HOOK_LOG hooks here **/         /** calling E_HOOK_LOG hooks here **/
         /** calling E_HOOK_DISPLAY hooks here **/         /** calling E_HOOK_DISPLAY hooks here **/
 +        /** calling E_HOOK_PROCESS hooks here **/
     }     }
- 
-    /** calling E_HOOK_PROCESS hooks here **/ 
  
     /** calling E_HOOK_BAILOUT hooks here **/     /** calling E_HOOK_BAILOUT hooks here **/
Line 74: Line 81:
  
 ==== Open discussions point ==== ==== Open discussions point ====
-Should the implementation contain pre and post hooks that would be empty by default? It would enable extensions to do some treatment at the early/lately phase.+Should the implementation also contain pre and post hook lists that would be empty by default? It would enable extensions to do some treatment at the early/lately phase.
  
 ===== Backward incompatible changes ===== ===== Backward incompatible changes =====
Line 89: Line 96:
 ===== Open issues ===== ===== Open issues =====
 None at the moment. None at the moment.
- 
-===== Proposed Voting Choices  ===== 
-This RFC does not suggest a language change, so a 50%+1 majority is required for passage. 
  
 ===== Patches and tests ===== ===== Patches and tests =====
-The patch is under creation by Patrick Allaert and Olivier Garcia+The patch has been created by Patrick Allaert and Olivier Garcia. 
 + 
 +PR available at: https://github.com/php/php-src/pull/1247
  
 ===== Implementation ===== ===== Implementation =====
 After the project is implemented, this section should contain: After the project is implemented, this section should contain:
- - the version(s) it was merged to +  * the version(s) it was merged to 
- - a link to the git commit(s)+  * a link to the git commit(s)
  
 ===== References ===== ===== References =====
Line 109: Line 115:
  
 ==== User land changes ==== ==== User land changes ====
-It may be interesting to provide changes in the userland so that a user function can be registered as a part of one of those hooks. However, that would complicate this RFC and we consider this as out of the actual scope while considering it as a future enhancement.+It may be interesting to provide changes in the userland so that a user function can be registered as a category of one of those hooks. However, that would complicate this RFC and we consider this as out of the actual scope while considering it as a future enhancement. 
 + 
 +===== Proposed Voting Choices ===== 
 +Proposed voting choices are Yes (vote in favor) or No (reject the proposed change) 
 + 
 +As this is not a language-changing RFC, a majority of 50%+1 is required to approve this RFC. 
 + 
 +===== Vote ====== 
 +<doodle title="improved_error_callback" auth="ogarcia" voteType="single" closed="true"> 
 +   * Yes 
 +   * No 
 +</doodle> 
 + 
 +===== Versions =====
  
 +  * 0.1: Initial RFC (2015-03-13)
 +  * 0.2: Changing API slightly + possibility to prepend hooks as suggested by Derick + fixing E_HOOK_PROCESS hooks placement (2015-04-07)
 +  * 0.3: Added hook's SUCCESS/FAILURE behaviour (2015-04-23)
 +  * 0.4: Closing vote for version 7.0 ("No go" because of feature freeze)
rfc/improved_error_callback_mechanism.1426499598.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools