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/04/08 00:26] – changed modify date patrickallaertrfc: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.2+  * Version: 0.4
   * Create Date: 2015-03-13   * Create Date: 2015-03-13
-  * Modify Date: 2015-04-08+  * 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 by **appending** a hook:+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, ... */
     }     }
Line 39: Line 39:
 </code> </code>
  
-**Prepending** is also possible in the case one want to execute a hook before the other of the same category:+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> <code c>
-    PHP_ERROR_HOOK_API my_logging_hook(PHP_ERROR_HOOK_ARGS) { 
-        /* Do some logging with error line number, filename, message, ... */ 
-    } 
- 
     zend_prepend_error_hook(E_HOOK_LOG, my_logging_hook);     zend_prepend_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:+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_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 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 82: 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 97: 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 =====
Line 117: 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 ===== ===== Versions =====
  
   * 0.1: Initial RFC (2015-03-13)   * 0.1: Initial RFC (2015-03-13)
-  * 0.2: Changing API a bit + possibility to prepend hooks as suggested by Derick + fixing E_HOOK_PROCESS hooks placement (2015-04-07)+  * 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.1428452790.txt.gz · Last modified: 2017/09/22 13:28 (external edit)