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/21 16:47] – 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-14+  * 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>
-    ZEND_API void my_logging_hook(ZEND_ERROR_CB_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 38: Line 38:
     zend_append_error_hook(E_HOOK_LOG, my_logging_hook);     zend_append_error_hook(E_HOOK_LOG, my_logging_hook);
 </code> </code>
 +
 +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: **Prepending** is also possible in the case one want to execute a hook before the others of the same category:
Line 49: Line 51:
 </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. The modification of hook lists must be done during the MINIT phase.
Line 95: 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 =====
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 =====
Line 123: Line 132:
   * 0.1: Initial RFC (2015-03-13)   * 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.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.1429634878.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools