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 revisionBoth sides next revision
rfc:improved_error_callback_mechanism [2015/04/21 16:47] – patrickallaertrfc:improved_error_callback_mechanism [2015/04/23 09:17] – Added hook's SUCCESS/FAILURE behaviour oliviergarcia
Line 1: Line 1:
 ====== PHP RFC: Improved Error Callback Mechanism ====== ====== PHP RFC: Improved Error Callback Mechanism ======
-  * Version: 0.2+  * Version: 0.3
   * Create Date: 2015-03-13   * Create Date: 2015-03-13
-  * Modify Date: 2015-04-14+  * Modify Date: 2015-04-23
   * 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: Under discussion
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 117: Line 118:
  
 ==== 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.
  
 ===== Versions ===== ===== Versions =====
Line 123: Line 124:
   * 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
  
rfc/improved_error_callback_mechanism.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1

Page Tools